Add sourceMapCallback option to enable advanced mapping use cases#69
Conversation
|
Don't worry about changes in dist, I'll rebuild it anyway. Looks good aside from breaking on cache (see comment inline) |
Note that the reason for passing a JSON string rather than an object reference is that Rollup mutates the object, leading to unpredictable behaviour.
|
I still don't fully get how caching works, but it looks to me like the sourcemap JSON will still only be parsed once (unless a file changes) with the how it's done now. |
|
Ok, I fixed some formatting and I think there was a bug in the way I was returning maps from cache, but rollup might have been covering for it. @lephyrus Could you check if current version works for you both clean and from cache? |
|
@ezolenko Yep, seems to work perfectly either way. Thanks for incorporating this feature so quickly! |
|
@ezolenko Can I ask if you're planning to do a release soon? |
|
Yep, most likely on the weekend sometime. I'm waiting on confirmation for one other issue, but that's not critical. |
sourceMapCallback option to enable advanced mapping use cases
Motivation
I am trying to do a Rollup build that transpiles my Typescript sources and specs for a Karma run, while also instrumenting the sources in a way that maps back to the original Typescript, without writing intermediate files to disk. I also want the final Rollup bundle to have correct source maps for in-browser debugging.
Problem
This plugin provides Rollup with the maps for the transformation from Typescript to Javascript, which correctly maps the resulting bundle to the original sources. When instrumenting the code with Istanbul as part of the process, the coverage info will not correctly apply to the original typescript, however. One approach is to use
remap-istanbul(e.g. viakarma-remap-coverage), but for that you need the source maps for the Typescript > Javascript transformation. These are not accessible fior a Rollup plugin, unless written to disk, which is not what this plugin does (for good reason). If I setinlineSourceMapto true in the Typescript compiler options, the Istanbul instrumenter correctly sees this as an "input sourcemap" and the coverage maps back to the Typescript sources perfectly. With such a configuration,rollup-plugin-typescript2on the other hand does not "see" the sourcemap and does not pass it back to Rollup, which leads to incorrect mappings for the generated bunde. The other way to solve this is to "manually" supply the Istanbul instrumenter with an input source map. This is what I got working.Solution
With the help of the modification proposed in this PR and a custom instrumenter plugin, I got the coverage report to match the Typescript sources while also having the correct source map for the bundle produces by Rollup. 🎉
Notes
clean: trueoption leads to problems with this approach, not sure why.package.lock.jsonis supposed to work. I really don't. 🤷♂️