From:  John Lenz <>
Date:  17 Jul 2013 23:13:12 Hong Kong Time

Re: Allow utilizing fragments of the minified file name for map file names


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
> in.
> re: default name mapping
> Sounds like the preferred default name mapping for source file "x.y" is
> "".  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
> which will be converted on the CDN to
> -  some-path/jquery.min.js and some-path/
> 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 -> (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 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
> 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?

Not that I know of.  Here are a list of source map munging I know people
would like:

* concatenate files and build an index source map
* replace some section of code and rebuild the source map (think sed +
source map)
* 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