-
Notifications
You must be signed in to change notification settings - Fork 361
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This is to follow the spec. As discussed in the [mailing list][1], when getting original positions, mappings end at the end of the line. However, when getting generated positions, mappings do not end at the end of the line. [1]: https://groups.google.com/forum/#!topic/mozilla.dev.js-sourcemap/Uo26hB5v5oY Getting original positions: For a generated position (L,C), find a mapping (L,X) such that X<=C and X is as great as possible. If no such mapping can be found, then there is no mapping for (L,C). This is because according to the spec, mappings end at the end of the line. Previously, we used to look for mappings on lines <L too. Getting generated positions: For a generated position (L,C), find a mapping (A,B) such that A<=L, A is as great as possible, B<=C and B is as great as possible. If there are multiple such mappings, I don't know which is or should be chosen. The spec doesn't say anything about it. The idea is at least that multiline source statements usually (ideally) only have a mapping at the beginning of the multiline statement. Then it is convienient to be able to get the generated position even if you're not at the first line. Note that this change is backwards incompatible. There were even tests for the faulty behavior in test/source-map/test-dogfooding.js! I had to change them, which of course breaks backwards compatibility.
- Loading branch information
Showing
3 changed files
with
42 additions
and
6 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
699dff1
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 have a case where mapping.generatedLine is
29
and needle.generatedLine is"029"
, which fails to pass the strict type check on line 315. Source map is being generated by a version of UglifyJS2.Relaxing this comparison resolves my issue, but is there any underlying problem to fix instead?
699dff1
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, work with numbers, not strings, of course.
699dff1
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.
BTW, it is possible to comment on certain lines (instead of writing "on line 315").
699dff1
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.
Aha! I didn't realize I could comment on a particular line -- thanks for the tip!
I've already monkey patched my version to perform the less strict comparison, but I wasn't sure if there was an even deeper problem that led to the disparate data types. Perhaps it's just an oddity of the various minifiers.
Thanks!
699dff1
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.
Where does
"029"
come from?699dff1
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.
Chalk this one up to PEBKAC -- upon digging deeper, I realized the source of the incorrect needle line/column values originated in my own code, and that it's perfectly reasonable for the code above to expect a numeric value. Sorry for the distraction!