Last modified: 2014-03-08 00:07:15 UTC
Source maps are a technique for mapping combined and minified JavaScript back to the original files. This could be very useful for debugging ResourceLoader in production mode. This can be necessary since behavior is different from debug mode (in ways other than minification). This is already supported in the Chrome debugger and Closure compiler, Mozilla is working on it (https://bugzilla.mozilla.org/show_bug.cgi?id=670002), and some other stacks have code to generate the maps. The spec is at https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit?hl=en_US&pli=1# and a good overview is at http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/ . The minified file points to the source map with a line like: //@ sourceMappingURL=/path/to/file.js.map or a header like: X-SourceMap: /path/to/file.js.map If we use a dynamic URL, that should allow doing it in production. It would build the source maps on demand (just like the minification) for people that have them enabled (and are debugging), without slowing the site for anyone else.
To clarify, I mean something like: //@ sourceMappingURL=/sourcemap.php?modules=... for the dynamic URL, with the response built and cached on demand.
Because of version numbers and caching, the link should probably include a hash instead of the module name (or both). ResourceLoader already has this infrastructure in place. When building packages, we only rebuild if the hash of the module contents are different. That hash is also output for debugging purposes with the cache key at the end of the package. We can use that same hash to tie a packaged response to the sourcemap, which we'll need to generate while packaging, not on-demand from the sourcemap request.
Could we also use the hash for identifying versions in regular requests, rather than the version parameter? That could potentially solve the problem of out of date HTML getting new JS+CSS.
Links: * http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/ * https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#source-maps * https://github.com/mozilla/source-map/ * http://blog.teamtreehouse.com/introduction-source-maps
(In reply to Matthew Flaschen from comment #3) > Could we also use the hash for identifying versions in regular requests, > rather than the version parameter? That could potentially solve the problem > of out of date HTML getting new JS+CSS. No. Firstly, the version number we have now would be more than enough for that purpose. The reason cached HTML is getting newer resources is because we explicitly *don't* embed version numbers or hashes of any kind in the HTML. That is not a bug but a feature (or bug fix) by design in the core of how ResourceLoader did what old $wgStyleVersion did wrong.
As for implementation, building on comment #2, the bottom of load.php javascript request would contain something like: /* cache key: enwiki:resourceloader:3957c1d7aa */ //# sourceMappingURL=load.php?action=sourcemap&id=3957c1d7aa Aside from incorporating a source map generator in PHP in the first place, doing this would be a pretty easy first step for minified -> unminifed mapping. However it's slightly more elaborate to also maintain where the modules came from to their respective individual non-concatenated files because when we're in the minifier, it's for the entire request as a whole. We'll have to maintain that state somehow and accumulate that context as we go on.
