Switch to @jridgewell/gen-mapping for sourcemap generation#14497
Switch to @jridgewell/gen-mapping for sourcemap generation#14497nicolo-ribaudo merged 6 commits intobabel:mainfrom
@jridgewell/gen-mapping for sourcemap generation#14497Conversation
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/51761/ |
| @@ -1 +1 @@ | |||
| {"version":3,"sources":["../src/foo.js"],"names":["arr","map","x","MULTIPLIER"],"mappings":";;AAAAA,GAAG,CAACC,GAAJ,CAAQ,UAAAC,CAAC;AAAA,SAAIA,CAAC,GAAGC,UAAR;AAAA,CAAT","sourcesContent":["arr.map(x => x * MULTIPLIER);"],"file":"foo.js"} | |||
| {"version":3,"file":"foo.js","names":["arr","map","x","MULTIPLIER"],"sources":["../src/foo.js"],"sourcesContent":["arr.map(x => x * MULTIPLIER);"],"mappings":";;AAAAA,GAAG,CAACC,GAAJ,CAAQ,UAAAC,CAAC;AAAA,SAAIA,CAAC,GAAGC,UAAR;AAAA,CAAT"} No newline at end of file | |||
There was a problem hiding this comment.
For reviewers: the various source map changes are just differences in the fields order; the contents are the same.
| line == null | ||
| ? undefined | ||
| : (filename || this._opts.sourceFileName).replace(/\\/g, "/"), | ||
| : filename?.replace(/\\/g, "/") || this._sourceFileName, |
There was a problem hiding this comment.
For reviewers: this._sourceFileName is already normalized in the constructor.
|
The Jest failures are caused by this PR, because of #14497 (comment). We can let them fail until the next patch, so that Jest can then update their snapshots. |
|
Given this is causing breaking changes in downstream projects, we can preserve the prop ordering of the sourcemap pretty easily. I'll push a commit. |
|
I mean, I wouldn't consider it a breaking change but just a "testing implementation details". The order of object keys is never considered part of the "public contract" 😛 It's enough to let @SimenB know about this so that he won't be surprised about the Jest failures when updating Babel, and we don't need to worry about preserving the original properties order. |
|
Hey! 👋 Exciting to see more of I totally agree key order shouldn't be part of the contract - will update our snapshots once there's a release 🙂 (you can probably just delete the test in the meantime in your e2e test if you want it green) |
This reverts commit accb758.
@jridgewell/gen-mapping for sourcemap generation
[`gen-mapping`](https://github.com/jridgewell/gen-mapping) is faster, smaller, and lighter sourcemap generation library. This also exposes a new `decodedMap` property on the result object. Decoded maps are free to create (it's a shallow clone of the `GenMapping` instance), and passing them to `@jridgewell/trace-mapping` is copy-free. With Babel [recently](babel/babel#14497) adding a `decodedMap` field, a dev could pass from the Babel transpilation to Terser without any added memory use for sourcemaps. And if there's a multi stage build process, a dev could use `@ampproject/remapping` to remap Babel, Terser, and (eg) a bundler's outputs without having to feed input maps into each stage.
[`gen-mapping`](https://github.com/jridgewell/gen-mapping) is faster, smaller, and lighter sourcemap generation library. This also exposes a new `decodedMap` property on the result object. Decoded maps are free to create (it's a shallow clone of the `GenMapping` instance), and passing them to `@jridgewell/trace-mapping` is copy-free. With Babel [recently](babel/babel#14497) adding a `decodedMap` field, a dev could pass from the Babel transpilation to Terser without any added memory use for sourcemaps. And if there's a multi stage build process, a dev could use `@ampproject/remapping` to remap Babel, Terser, and (eg) a bundler's outputs without having to feed input maps into each stage.
* Switch to GenMapping for sourcemap generation [`gen-mapping`](https://github.com/jridgewell/gen-mapping) is faster, smaller, and lighter sourcemap generation library. This also exposes a new `decodedMap` property on the result object. Decoded maps are free to create (it's a shallow clone of the `GenMapping` instance), and passing them to `@jridgewell/trace-mapping` is copy-free. With Babel [recently](babel/babel#14497) adding a `decodedMap` field, a dev could pass from the Babel transpilation to Terser without any added memory use for sourcemaps. And if there's a multi stage build process, a dev could use `@ampproject/remapping` to remap Babel, Terser, and (eg) a bundler's outputs without having to feed input maps into each stage. * Apply suggestions from code review Co-authored-by: Fábio Santos <fabiosantosart@gmail.com> * Fix dependency * Switch to source-map compatible @jridgewell/source-map This preserves API compatibility, so that loading source-map in the browser is still supported. * Update TS types * Support source-map's async SourceMapConsumer * Fix sourcesContent check with source-map's SourceMapGenerator Co-authored-by: Fábio Santos <fabiosantosart@gmail.com>
source-mapand switch to@jridgewell/gen-mappingThis removes the final use (of an ancient version 5yo version) of
source-map. This gives a few benefits:Somewhat controversial, but I'm making
rawMappingsslower. Why? Because it isn't used by anyone. And, we're always generating a map output (becausebabel-clireads the.mapgetter). I think it's more important to prioritize the regular sourcemap than therawMappings. If someone wants to userawMappingsfor speed, I'd encourage them to use the newdecodedMapfield, and@jridgewell/trace-mappingto trace or@ampproject/remappingto remap. Regardless, adding items to theGenMappingshould be just as fast as pushing items onto the_rawMappings, and possibly considerably faster since the raw mappings covers every line/column vs the gen-mapping's per-line array.