The list is good but I'd also like to propose a more drastic change (it might not be implemented but I still think we should at least put that out) - it's what Gibson said amongst others - 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:

<link rel="sourcemaps" href="path/to/manifest.json">

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.

Thoughts?

I dunno, if we go with doing stuff in the document itself, why not add a sourcemap attribute to the script tag?

My opinion is that we shouldn't have the info in the source file itself. It involves too much (failing) trickeries when you consider file renaming.

Replying to [comment:3 jaubourg]:

I dunno, if we go with doing stuff in the document itself, why not add a sourcemap attribute to the script tag?

Didn't think of that. We'd need 2 attributes, though, sourcemap and source (the latter for unminified source) so that the map file doesn't contain any names/paths.

This wouldn't work for dynamically loaded scripts having //# sourceUrl set though I'm not sure how big a concern that is.

My opinion is that we shouldn't have the info in the source file itself. It involves too much (failing) trickeries when you consider file renaming.

100% agreed.

This wouldn't work for dynamically loaded scripts having //# sourceUrl set though I'm not sure how big a concern that is.

It would using script tag injection.

The more I think about it, the more I like fingerprinting.

• source.min.js (or raw compressed source) ''starts'' with code indicating the hex-encoded hash of a valid map and optionally a location for it (either absolute or relative to the source location, and in both cases allowing for a "same name" syntax); e.g. //# sourceMap MD5=daef2e232e01d25520708543c48db61f URL={basename .js}.map
• hash algorithms for which support is required are documented in the spec, and very limited
• sourceMap parameters can be specified via out-of-band mechanisms like HTTP headers, element attributes, or manual association in developer tools
• source.min.map is JSON like the current spec but with version > 3 and no file property, and is ignored in the case of hash mismatch
• uncompressed source files remain unchanged

Replying to [comment:6 gibson042]:

The more I think about it, the more I like fingerprinting. * source.min.js (or raw compressed source) ''starts'' with code indicating the hex-encoded hash of a valid map and optionally a location for it (either absolute or relative to the source location, and in both cases allowing for a "same name" syntax); e.g. //# sourceMap MD5=daef2e232e01d25520708543c48db61f URL={basename .js}.map

There's still the location in the file which I wanted to avoid.

* hash algorithms for which support is required are documented in the spec, and very limited * sourceMap parameters can be specified via out-of-band mechanisms like HTTP headers, element attributes, or manual association in developer tools

HTTP headers could work for CDNs but not for regular devs. Manual association is not sth jQuery should care about; I'd go either for the manifest approach or attributes on script tags.

* source.min.map is JSON like the current spec but with version > 3 and no file property, and is ignored in the case of hash mismatch

+1 for removing the file field.

* uncompressed source files remain unchanged

Has anyone opened a bug at crbug.com on Chrome's unwanted behaviour? Someone prolly thought this was a great feature; it would still be useful, if I was debugging problems with my sourcemaps or something, but otherwise, you don't want to see those 404's. I'd ask to make the default "quiet" with an option to log the "warnings".

Also, consider embedding the original source in the sourcemap file, in which case you only need the min.js and map file to debug. More thoughts here: http://pmuellr.blogspot.com/2013/10/sourcemap-best-practices.html

#14433 is a duplicate of this ticket.

If we decide to keep sourcemaps, #14433 would be another impediment.

Previous discussion in the sourcemap group: https://groups.google.com/forum/#!topic/mozilla.dev.js-sourcemap/rIt4kvlC6GI

@dmethvin it wouldn't be, that issue is fixed. :)

Pull request: https://github.com/jquery/jquery/pull/1424

I've kept the source map comment for manually compiled files as they're not causing as problems; manual copying+renaming of some files from CDNs do.

Fix #14415. Remove the source map comment in the release script. Close gh-1424.

Changeset: 562145e887cc42ce8c9c9cd2c6e946ff01e6731d