Skip to content
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

Wiring up existing source maps of transpiled codes #692

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

netj
Copy link

@netj netj commented Jun 14, 2014

When generateSourceMaps option is enabled, r.js now detects if the module to be concatenated already declares a source map. It tries to load the existing source map, and translates line numbers of all mappings in that source map to those of the final output.

This fixes most of #470, and works well as long as optimize option is set to none. Some work still remains to pass a correct --in-source-map option to UglifyJS when also uglifying. Currently, UglifyJS ignores r.js's carefully generated source map producing a bogus one if optimize option is set to uglify2.

Used https://github.com/lydell/source-map-url (v0.2.0) for detecting sourceMappingURL= comments from the code.

netj added 2 commits June 14, 2014 00:01
When `generateSourceMaps` option is enabled, r.js now detects if the
module to be concatenated already declares a source map. It tries to
load the existing source map, and translates line numbers of all
mappings in that source map to those of the final output.

This fixes most of requirejs#470, and works well as long as `optimize` option is
set to `none`.  Some work still remains to pass a correct
`--in-source-map` option to UglifyJS when also uglifying.  Currently,
UglifyJS ignores r.js's carefully generated source map producing a bogus
one if `optimize` option is set to `uglify2`.

Used https://github.com/lydell/source-map-url (v0.2.0) for detecting
sourceMappingURL= comments from the code.
@netj
Copy link
Author

netj commented Jun 14, 2014

It seems the issue with optimize: "uglify2" could be the fault of rather UglifyJS, not r.js. I've been testing this by compiling a bunch of 3rd party JS libraries with some of my CoffeeScript code. I wasn't able to generate a correct source map with either r.js's optimize: "uglify2" option or through the uglify command with all the right options (including --in-source-map).

However, interestingly, when I uglify not only the final code from r.js but also require.js into a single file keeping other source map options exactly the same as before, a correct source map is generated, and I can see line numbers in .coffee files from my browser. (Caveat: tested only with WebKit) After a look into the code, r.js' implementation of the interaction with UglifyJS2 (optimize.js) appears to be pretty complete to me. So I'm suspecting this could be due to a bug in UglifyJS. For example, UglifyJS could be dropping many mappings from the given inSourceMap, as it preserves only some mappings of inSourceMap for the lines/columns that were selectively asked during output.

@Reson4nc3
Copy link

Would this make Typescript files source map all the way back to typescripted code even after bundling with r.js, as long as optimize is set to none?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants