On Tuesday, July 16, 2013 8:06:48 PM UTC-4, Paul Irish wrote:
As the author of the chromium bug that Paul referenced, thought I'd chime in.
re: default name mapping
Sounds like the preferred default name mapping for source file "x.y" is "x.y.map". This should work with the css sourcemaps as well, right? Note that's not what jquery is doing today - so, they'll change to produce things like:
- jquery-2.0.0.min.js and jquery-2.0.0.min.js.map
which will be converted on the CDN to
- some-path/jquery.min.js and some-path/jquery.min.js.map
Is this workable with the CDN folk?
re: //# implicitSourceMap
This seems like a good enough way to handle this, today, instead of assuming there's a map with every .js file. Tooling can simply dump this into sourcemap-able things without having to do any "path math" on the source file name/path.
I think I can see a case for prefixing the default map - I've found for some scenarios that I'd have to dump all the original source into my scripts directory on the server to get the sourcemap bits to work, which to me is icky. I'd prefer to dump them in a "debug" subdirectory or some such instead. But I haven't played with this enough to know what I really want - for now, at least cutting down on explicit URLs is something that makes me happy.
re: "For inline scripts in a page do you still just append the ".map"?"
I would vote no, as even the best case of http://example.com/.map seems ... bad.
If you've got enough JS goop embedded in your HTML file that sourcemaps become useful, then I think you can afford to use an explicitly named solution.
But I wonder if this affects folks who do dynamic script loading - eg, require.js. Is James Burke following this?
re: "datauri sourcemap is a strong solution here to name changes" from Paul
I disagree with this, at this point. The implication is that you have a debug version and a non-debug version of your wad. Because you don't want to use the debug version in production. Implying CDNs will have to host both, and users will have to hardcode in their app which one they're using. I also pointed out in the the bug Paul referenced, that files with sourcemap dataurls end up causing problems with editors when you accidently open them in your edit sessions. Ya, stupid editor problem, not your fault, but ... it hits me where I live (my editor). I've tooled around sourcemap-gen'ning tools which dataurl-ize sourcemaps to extract the sourcemap to a separate file and replace the dataurl with an actual URL.
Speaking of, it would be nice to have a sourcemap swiss army knife, which could take a blob of files that had sourcemap goodness in them, and do various kinds of surgery on them - for example, my example of stripping out a dataurl-ized sourcemap into a separate file. Does such a thing exist?