build: patch terser to create proper source-maps [do not merge] #32277
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
mhevery
added
the
area: build & ci
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
force-pushed
the
build/patch-terser-output-proper-source-maps
branch
from
56ca1ea
to
bf85cd4
Compare
filipesilva
approved these changes
Oct 2, 2019
|
@devversion What's the status with this PR? |
|
@jessicajaniuk This is still an issue with Terser; resulting in incorrect size measurements/goldens in the repo. Though there isn't a good fix for this yet. I'm closing this for now but want link to terser/terser#382 |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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 terser is in a broken state where technically unmapped
bytes in the input file are mapped back to random source files.
To clarify the term "unmapped bytes": In the input file there are bytes
which cannot be mapped back to any source file. This can happen if code
will be generated by tools automatically. e.g. TSC generating decorator helpers, or
rollup creating bundles of multiple files (there will be boilerplate to merge multiple
files into a bundle). These bytes do not originate from any source-file and therefore
are "unmapped". Read more about 1-variable length segments in the source-map spec
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-maplibrary.Terser reverted the fix that hit the bug in
mozilla/source-mapasthey wanted to unblock consumers that use the latest
source-mappackage. Problem is that the bug in the
source-mappackage is widelyspread and there doesn't seem to be a fix for it any time soon. Meaning
that source-maps need to stay broken/incorrect as fixing them would
always cause developers to hit the
source-mapbug...This PR should just be an example of how correct source-maps
should look like (helpful when comparing size differences)
See
source-mapbug: mozilla/source-map#385See Terser fix: terser/terser#342.