-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Source map support #163
Source map support #163
Conversation
thanks for working on this. as far as grokking sourcemaps goes, I've seen a bunch of different visualization tools, but this is pretty groovy, IMO: https://evanw.github.io/source-map-visualization/ |
Thanks for the link! Visualization looks great, but unusable, unfortunately. The author, it seems, forgot to provide a way to upload source files. The generated file and it map, obviously, is not enough. But I found another same-named project -- https://sokra.github.io/source-map-visualization. |
Thank for the for working in the much better approach, looking forward to having this feature. When do you think this will be ready? Looking into your implementation I have a few doubts.
push(new SourceNode(
ast.topLevelInitializer.codeLocation.start.line,
node.codeLocation.start.column - 1,
options.grammarSource,
ast.topLevelInitializer.code,
node.type
));
function buildFunc(a, i) {
return new SourceNode(
null, null, options.grammarSource,
[
"\n var " + f(i) + " = function(" + a.params.join(", ") + ") {",
a.source,
"};"
],
f(i)
);
} Will align incorrectly the action code with the beginning of the line (before var), the intention wasn't something like this? new SourceNode(null, null, null, [
"\n var " + f(i) + " = function(" a.params.join(", ") + ") {",
new SourceNode(null, null, options.grammarSource, a.source),
"};"
],
a.source
);
|
Yes, that's what it's designed for.
As you can see in the regenerated
Only code blocks need source map because all other pieces of grammar you cannot debug. I plan to finish work on this after #167 will merge in order to avoid merge conflicts in CLI, but @hildjj taken a little vacation, I think. Actually, locally I've already done some job and fixed some moments after testing with visualizer. Actually, this work can be finished in couple days. I think I'll do it this weekend. |
Yes, sorry, I've had other things I was working on. I'll circle back around to 167 in the next few days. |
Well, it was designed to receive one Node (token), and the corresponding position in the source file, if you send a big chunk only the first token will be mapped, and in this case the first token is not an identifier, so it is like if it was not mapped.
Sorry if that was ambiguous, when I said alignment I meant the association between the position in the generated code and the position in the source code. It seems you are aligning
What do you mean with I cannot debug? By debugging I mean to be able to run step by step over the pieces that may consume some input.
Thank you! |
Hi @Mingun and @hildjj I am looking forward to use this feature. I closed my pull request after you mentioned this work, since I think is not the best use of my time to work on code that someone else is already doing. Are you still working on this or should I resume what I started, or would you prefer to setup a branch that I can work from this work as a starting point. Thanks |
Sorry for the delay, the new old interesting project captured my attention :). I will try to mend.
Large parts of the generated parser code have not any representation in the source grammar. I've tested my mapping on https://sokra.github.io/source-map-visualization and it seems it works quite well. There are some errors in the mapping but it seems unavoidable because source-map by design maps only start coordinates of chunks, but not their length, so you can observe artifacts as on that image: If you has thoughts how this can be fixed, you are welcome!
In my tests on https://sokra.github.io/source-map-visualization it seems to working correctly.
I mean that this is not an executable code. You cannot put breakpoint in it. You shows me an interesting way to use the map, I not thinking about it. But I do not really understand how this can be done now because lengths of original and generated strings is different ( |
That's fine, many projects out there
Yes I have an idea about how to do this, the javascript should be the easy part. Also it would be fine if we extended the javascript code rule in the peggy parser, so that we could build the JS AST and also report errors properly. But that is a big change.
Thanks, when I have the opportunity I will prepare a PR with the source maps only for the embedded source maps. |
I've finished this and it is ready for final review.
So you can compare and choose what your like better. If an alternative API is more preferable, I add this commit to that PR. Because of the mozilla/source-map#444 you can't use |
Nice work. I like the first option you propose. |
@hildjj , I forgot to mention: the first commit should also include changes in |
We had some issue testing on node10 with the newer package-lock format at some point. I've been generating the package-lock file with I continue to prefer solving this problem by not checking in the package-lock file, since we have no runtime dependencies. |
If you rebase, I'll prioritize reviewing this over the next few days. I'd like to get this in soon, have a few people try it, then do a release next week if possible. |
I plan to finish this this weekend. |
Rebased: new changes in those 2 commits: https://github.com/peggyjs/peggy/pull/163/files/e5c3522eeb8e05f694b72dbe09f10223db3c9d5f..74dbbfa62e203f9b862151ce63ca0b010e968a1a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly minor stuff, except that we need to get rollup to work cleanly, and have the output work in the browser. I like the follow-on patch with the API change, so let's go ahead and work from that point.
return toSourceNode(node.code, node.codeLocation, "$" + node.type); | ||
} | ||
|
||
return node.code; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be able to reach this with a plugin
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you expand your thought? If you think about something like ts-pegjs
which originally will have a TypeScript code here, it should already translate it to the JS, but I suspect it have their own generate-ts
pass. Or you talk about extracting this function into utils
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry i was terse. :) This line is missed in code coverage, and i think it should not be too difficult to write a small plugin in the test that would reach this line of code.
After we merge this, I'm going to do a PR that adds a bunch of code coverage, so I can fix it up then if you like.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I spent some time to understand that nyc
command in the package.json
used only for debug CLI and not required for ordinally run, because jest
has built-in support for coverage, but the results are not showing in the console. I think we need to fix that. I can prepare a PR for that if you not already handle that in your upcoming PR.
Cover this line, will update PR soon
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be a separate issue. Assign it to me, and I'll fix it when I touch the CLI.
@@ -65,6 +65,7 @@ | |||
"rimraf": "^3.0.2", | |||
"rollup": "^2.56.2", | |||
"sinon": "^11.1.2", | |||
"source-map": "^0.7.3", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be "^0.8.0-beta.0"
, which includes a fix so that rollup doesn't pull in fs
and path
. Then there's a change needed to rollup.config.js, add json(),
to line 31 so that the mapping table included by that version of source-map will get pulled in correctly..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...and then there are a couple of other rollup issues behind that which I'm not sure why we haven't seen before. I'm going to put those aside for the moment and review the rest of this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. Actually, I doubted should I depend on the beta version of the project that not seems to be actively developed for 2 years for now. Even now, npm offers to install version 0.6.1
instead of the last available version (although now I realized that this is due to the fact that such version is specified in package-lock.js
at the top level)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should rethink our dependency on source-map. All we need is the generator, and I think it's the consumer that depends on tr46, etc, which adds the huge tables. I wonder if we could make https://github.com/a-la/source-map-generator work. It would need at least one patch to not use node's url
, and rely on the built-in URL
instead, but we can send them a PR or fork if needed. I think this would make rollup a lot easier and reduce the size of the generated code by a lot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm working up that PR for source-map-generator, just in case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't recall the specific issue I had with rollup, but I'll check out your current head to see if it shows up again.
The way I solved the test issue in source-map-generator was to use the original source-map as a dev dependency. I think that's what you said you tried. Anyway, I'll take a look here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All our dependencies are dev dependencies, so yes, I tried have both and right now it seems that having https://github.com/hildjj/source-map-generator is just redundant
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I almost have it working here, I think. Give me another hour or so, and I'll send a PR to your repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See Mingun#1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes merged
@@ -31,6 +31,7 @@ Follow these steps to upgrade: | |||
— more powerful than traditional LL(_k_) and LR(_k_) parsers | |||
- Usable [from your browser](https://peggyjs.org/online), from the command line, | |||
or via JavaScript API | |||
- [Source map](https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Use_a_source_map) support |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This worked when I added a //# sourceMappingURL=
comment to the end of the generated .js file, which I think should be done automatically.
This pointed out that the filenames in the .map file might need to be tweaked; from the project root, try ./bin/peggy.js examples/fizzbuzz.peggy --source-map
. The map file includes "sources":["examples/fizzbuzz.peggy"]
which should probably instead be `"sources":["fizzbuzz.peggy"]". The filename should be relative to the .map file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that automatic appending of this line will be desired behavior in each case, mostly because I don't known how people will use source-map feature. Source maps could be hosted not in the same directory where it was generated and only the user know the right place. Adding this line is a trivial task, so I leaved it out of scope of my PR. We can firstly gather the feedback and add this line later if users will complain about it. Or, if you have a clear vision, I can add it now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the line should be auto-appended in the CLI only. We can add an option for inlining it later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The filename should be relative to the .map file
Done.
I think the line should be auto-appended in the CLI only. We can add an option for inlining it later.
I'll leave that for the next PRs. There a many options to forming such URL. For example, someone can want to form a data URL embedding generated source map in it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is going to take a few more PRs before we're ready to release, and I don't want to docs to be wrong for that long a time, so I'm going to create a "1.3" branch that we can merge this into, and start to merge other work into as well.
After this lands in the 1.3 branch, and we add in #199, we should have a better way to talk about how to test whether the maps are working as expected. Make sense @Mingun?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think this is a good plan
@@ -93,10 +94,10 @@ const compiler = { | |||
|
|||
switch (options.output) { | |||
case "parser": | |||
return eval(ast.code); | |||
return eval(ast.code.toString()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this is going to break ts-pegjs
? I guess .toString
is safe to add to a string, but I wonder if there's anything else that will break.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you worried that ts-pegjs
might have replaced the code
with its object? Yes, it should be upgraded to correctly handle the new sourceMap
option (or new "output-with-map"
output variant)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's get @pjmolina 's opinion early. We can move several of the functions in generate-js into utils to make them easier to reuse, if that would help.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll try to address review comments this week.
@@ -31,6 +31,7 @@ Follow these steps to upgrade: | |||
— more powerful than traditional LL(_k_) and LR(_k_) parsers | |||
- Usable [from your browser](https://peggyjs.org/online), from the command line, | |||
or via JavaScript API | |||
- [Source map](https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Use_a_source_map) support |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that automatic appending of this line will be desired behavior in each case, mostly because I don't known how people will use source-map feature. Source maps could be hosted not in the same directory where it was generated and only the user know the right place. Adding this line is a trivial task, so I leaved it out of scope of my PR. We can firstly gather the feedback and add this line later if users will complain about it. Or, if you have a clear vision, I can add it now.
@@ -93,10 +94,10 @@ const compiler = { | |||
|
|||
switch (options.output) { | |||
case "parser": | |||
return eval(ast.code); | |||
return eval(ast.code.toString()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you worried that ts-pegjs
might have replaced the code
with its object? Yes, it should be upgraded to correctly handle the new sourceMap
option (or new "output-with-map"
output variant)
return toSourceNode(node.code, node.codeLocation, "$" + node.type); | ||
} | ||
|
||
return node.code; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you expand your thought? If you think about something like ts-pegjs
which originally will have a TypeScript code here, it should already translate it to the JS, but I suspect it have their own generate-ts
pass. Or you talk about extracting this function into utils
?
@@ -65,6 +65,7 @@ | |||
"rimraf": "^3.0.2", | |||
"rollup": "^2.56.2", | |||
"sinon": "^11.1.2", | |||
"source-map": "^0.7.3", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. Actually, I doubted should I depend on the beta version of the project that not seems to be actively developed for 2 years for now. Even now, npm offers to install version 0.6.1
instead of the last available version (although now I realized that this is due to the fact that such version is specified in package-lock.js
at the top level)
Where do we stand on this? I've talked to the folks a Moz, and we're figuring out a better way to move forward in the long run. In the short run, it's ok to depend on https://github.com/hildjj/source-map-generator |
I'll return to this this weekend. Need to run coverage and see where I can improve it, as you noticed. Ok, I'll switch to https://github.com/hildjj/source-map-generator. |
Such joins stringify SourceNode's prematurally
Again, this prevents premature stringification of the SourceNodes
Here just for uniformity
Regenerate parser, add documentation and tests
… be written Also exit with error code 2 when CLI fails because of invalid test input and update CLI tests to check exit code
… of `sourceMap` flag
Latest changes:
Do not use https://github.com/hildjj/source-map-generator, because I need |
…lder version or dropping node 10 support.
Please move base branch to 1.3 and I'll merge. |
Done |
Draft PR for getting feedback about general conception.
Probably will fix #105, but I need to learn how I can test that. I've never working with source maps before so I need learn how to use it for debugging. If anyone have a link to a good course, please let me known.
Notes about implementation: I'm not sure that introducing a new
output
type is a good idea. Maybe a new optionsourceMap: true
will be better?