Fix compressed source-maps have non-terminated segments #342
Conversation
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
devversion
force-pushed
the
fix/compressed-source-maps-incorrect-segments
branch
2 times, most recently
from
a60ff77
to
904002f
Compare
filipesilva
reviewed
Apr 26, 2019
|
I second @filipesilva in his comment, so please do change that one thing :) I very much appreciate the effort that went into this PR. Source map issues are pesky, hard to debug, hard to track the origin of, and just a major pain in the backside in terms of DX. |
Currently when `terser` compresses a given input file that comes with a source-map, but the source-map does not have mappings for all code parts in the input file. e.g. the input file has been generated and some specific code-parts have been generated which are not originating from any source-file. In that case if mappings before the "generated code" are collected, and the original file location for the "generated code" comes after previous segments for the same line, Terser just ignores the fact that there is no original location and the previous segment is not terminated. This causes the "generated code" incorrectly to be mapped to the previous segment/ original source location.
devversion
force-pushed
the
fix/compressed-source-maps-incorrect-segments
branch
from
904002f
to
4c7b61d
Compare
|
@fabiosantoscode Sure. I just didn't have time to address that comment until now. Thanks for the feedback you all! Updated now! 😄 |
|
Hi @fabiosantoscode, is there anything I could do to move this forward? Happy to help in case something is unclear, or if you have any concerns in regards to increased source-map size due to more mappings. |
|
@devversion thanks for the ping, I'm merging this. Thank you very much for your contribution! |
|
Thank you! @fabiosantoscode 😄 |
fabiosantoscode
added a commit
that referenced
this pull request
Jun 30, 2019
This reverts commit 7d47254.
fabiosantoscode
added a commit
that referenced
this pull request
Jun 30, 2019
devversion
added a commit
to devversion/angular
that referenced
this pull request
Aug 22, 2019
Currently terser is in a broken state where technically unmapped bytes in the input file are randomly mapped back to source files. "unmapped bytes" are bytes in the input file (that should be minified), which cannot be mapped back to any source file. This is totally valid as some code will be generated by rollup in order to create bundles of multiple files. These bytes do not originate from any source-file and therefore do not map. In the current state of Terser where unmapped bytes are mapped to random source-files, size tracking tools are not able to determine accurate payload size contribution numbers of individual source-files, nor do the broken source-maps help with debugging Angular packages as some bytes are incorrectly mapping to a wrong file (this is not a big deal though as the generated code is not likely to be debugged). For context why we try to fix the terser bug on our side now: A PR to fix this bug on the terser side has been submitted but it had to be reverted due to a bug in the latest `mozilla/source-map` library. Terser reverted the fix that hit the bug in `mozilla/source-map` as they wanted to unblock consumers that use the latest `source-map` package. Problem is that the bug in the `source-map` package is widely spread and there doesn't seem to be a fix for it any time soon. Meaning that source-maps needs to stay broken/incorrect as fixing them would always cause developers to hit the `source-map` bug... See `source-map` bug: mozilla/source-map#385 See Terser fix: terser/terser#342.
devversion
added a commit
to devversion/angular
that referenced
this pull request
Sep 11, 2019
Currently terser is in a broken state where technically unmapped bytes in the input file are randomly mapped back to source files. "unmapped bytes" are bytes in the input file (that should be minified), which cannot be mapped back to any source file. This is totally valid as some code will be generated by rollup in order to create bundles of multiple files. These bytes do not originate from any source-file and therefore do not map. In the current state of Terser where unmapped bytes are mapped to random source-files, size tracking tools are not able to determine accurate payload size contribution numbers of individual source-files, nor do the broken source-maps help with debugging Angular packages as some bytes are incorrectly mapping to a wrong file (this is not a big deal though as the generated code is not likely to be debugged). For context why we try to fix the terser bug on our side now: A PR to fix this bug on the terser side has been submitted but it had to be reverted due to a bug in the latest `mozilla/source-map` library. Terser reverted the fix that hit the bug in `mozilla/source-map` as they wanted to unblock consumers that use the latest `source-map` package. Problem is that the bug in the `source-map` package is widely spread and there doesn't seem to be a fix for it any time soon. Meaning that source-maps needs to stay broken/incorrect as fixing them would always cause developers to hit the `source-map` bug... See `source-map` bug: mozilla/source-map#385 See Terser fix: terser/terser#342.
devversion
added a commit
to devversion/angular
that referenced
this pull request
Sep 13, 2019
Currently terser is in a broken state where technically unmapped bytes in the input file are randomly mapped back to source files. "unmapped bytes" are bytes in the input file (that should be minified), which cannot be mapped back to any source file. This is totally valid as some code will be generated by rollup in order to create bundles of multiple files. These bytes do not originate from any source-file and therefore do not map. In the current state of Terser where unmapped bytes are mapped to random source-files, size tracking tools are not able to determine accurate payload size contribution numbers of individual source-files, nor do the broken source-maps help with debugging Angular packages as some bytes are incorrectly mapping to a wrong file (this is not a big deal though as the generated code is not likely to be debugged). For context why we try to fix the terser bug on our side now: A PR to fix this bug on the terser side has been submitted but it had to be reverted due to a bug in the latest `mozilla/source-map` library. Terser reverted the fix that hit the bug in `mozilla/source-map` as they wanted to unblock consumers that use the latest `source-map` package. Problem is that the bug in the `source-map` package is widely spread and there doesn't seem to be a fix for it any time soon. Meaning that source-maps needs to stay broken/incorrect as fixing them would always cause developers to hit the `source-map` bug... See `source-map` bug: mozilla/source-map#385 See Terser fix: terser/terser#342.
devversion
added a commit
to devversion/angular
that referenced
this pull request
Oct 2, 2019
Currently terser is in a broken state where technically unmapped bytes in the input file are randomly mapped back to source files. "unmapped bytes" are bytes in the input file (that should be minified), which cannot be mapped back to any source file. This is totally valid as some code will be generated by rollup in order to create bundles of multiple files. These bytes do not originate from any source-file and therefore do not map. In the current state of Terser where unmapped bytes are mapped to random source-files, size tracking tools are not able to determine accurate payload size contribution numbers of individual source-files, nor do the broken source-maps help with debugging Angular packages as some bytes are incorrectly mapping to a wrong file (this is not a big deal though as the generated code is not likely to be debugged). For context why we try to fix the terser bug on our side now: A PR to fix this bug on the terser side has been submitted but it had to be reverted due to a bug in the latest `mozilla/source-map` library. Terser reverted the fix that hit the bug in `mozilla/source-map` as they wanted to unblock consumers that use the latest `source-map` package. Problem is that the bug in the `source-map` package is widely spread and there doesn't seem to be a fix for it any time soon. Meaning that source-maps needs to stay broken/incorrect as fixing them would always cause developers to hit the `source-map` bug... See `source-map` bug: mozilla/source-map#385 See Terser fix: terser/terser#342.
devversion
pushed a commit
to devversion/terser
that referenced
this pull request
Oct 31, 2021
…ts (terser#342)" (terser#381)" This reverts commit 7c1e9cc.
devversion
added a commit
to devversion/terser
that referenced
this pull request
Oct 31, 2021
…ts (terser#342)" (terser#381)" This reverts commit 7c1e9cc.
jridgewell
added a commit
to ampproject/remapping
that referenced
this pull request
Nov 11, 2021
jridgewell
added a commit
to ampproject/remapping
that referenced
this pull request
Nov 11, 2021
devversion
added a commit
to devversion/terser
that referenced
this pull request
May 20, 2022
…ts (terser#342)" (terser#381)" This reverts commit 7c1e9cc.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently when
tersercompresses a given input file that comeswith a source-map, but the source-map does not have mappings for
all code parts in the input file. e.g. the input file has been generated
and some specific code-parts have been generated and are not
originating from any source-file (i.e. rollup boilerplate to create bundle)
In that case if real mappings before the "generated code" are collected, and
the original file location for the "generated code" is determined after previous
mappings for the same line have been recorded, Terser just ignores the fact that
there is no original location and the previous segment is not terminated. Meaning that the"generated code" incorrectly maps to the previous segment.