From:  "Fitzgerald, Nick" <nfitzgerald@mozilla.com>
Date:  23 Oct 2013 02:41:37 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.js-sourcemap
Subject:  

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

NNTP-Posting-Host:  63.245.216.66

On 10/20/13 12:35 PM, Michał Gołębiowski wrote:
> On Wednesday, October 2, 2013 6:26:45 PM UTC+2, Fitzgerald, Nick wrote:
>> On 10/2/13 9:15 AM, Fitzgerald, Nick wrote:
>>
>>> Adding such a pragma to the spec would solve a lot of things but not all
>>> (e.g. when site owner copies just the minified file without a map & source).
>> I don't see a way to get around this without embedding the source map
>>
>> and source content. Can you think of a way?
> There's a way that also solves a huge bunch of other problems - i.e. not putting the info about the map file into the minified file at all but to link it in another way, e.g. via special attributes on script tags. I had a slightly different proposal but in a similar spirit; I'll re-post my response from jQuery bug tracker (http://bugs.jquery.com/ticket/14415#comment:2) as it's relevant here:
>
> I'd like to propose a more drastic change to at least create an alternative way of defining the map & source files - a site would be declaring a link to the manifest file in its HTML, like:
>
> 
>
> The manifest file would be a JSON with mappings in a format like:
>
> "path/to/jquery-2.1.0.min.js": [ "path/to/jquery-2.1.0.min.map", "path/to/jquery-2.1.0.js" ]
>
> The site would then download the map & source files for minified files on opening DevTools or on debugging start. The map file should not reference the minified file by name but can do it e.g. via an md5 hash (thx Gibson for the suggestion). The map file would also declare the path (full or relative) to the source file.
>
> In this way we achieve a very important thing - a developer that either doesn't know about sourcemaps or doesn't care about it could copy the files they want and the new site just wouldn't have source map functioning but no errors would be caused by that - since the manifest is missing, DevTools wouldn't even try to find sourcemap files.
>
> Another problem was mentioned by Dave during a meeting: current sourcemap spec breaks one important assumption - that vendor minified files can have clearly defined md5/sha1/etc. hash that lets people quickly check if their vendor file isn't hijacked in any way. Putting comments that depend on file names in the minified file breaks that assumption, a manifest approach avoids this problem completely.
>
> To the list of wins of the approach with the manifest file is also a slight size saving for end users since they download the file without comments that are interested only to devs that do debugging.
> _______________________________________________
> dev-js-sourcemap mailing list
> dev-js-sourcemap@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-js-sourcemap
I don't like this because

1) It introduces yet another file that we have to spec out, the manifest
file.

2) Instead of having one HTTP request before you can start debugging,
you now have two: fetch the manifest, find out if your source has a
source map, fetch the source's source map, start debugging.

Instead, I think the sourcemap="...." HTML attribute is a better way
forward.