On Wed, Jul 17, 2013 at 5:15 AM, Patrick Mueller wrote:
> 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
> 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.
ImplicitSourceMap is only be required if (1) you want to support renaming
of the source map file mylib.min.js.map -> mylib-0.9.min.js.map (2) you
can't use relative mapping.
> 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.
The HTML itself would need an .map file unless the inline js is using //#
> 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
> 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?
Not that I know of. Here are a list of source map munging I know people
* concatenate files and build an index source map
* replace some section of code and rebuild the source map (think sed +
* remap source file locations
* inline sources into the source map
* (you) extract sources from a source map
* invert the source map (source -> generated code)
* view source and generated code side-by-side
Likely people have built all of these independently
> dev-js-sourcemap mailing list