From:  Brian Slesinsky <>
Date:  13 Jun 2014 06:46:56 Hong Kong Time

Re: Adding checksums to source maps


I think that sounds pretty reasonable. Agreed that we're not going to put
UUID's in source files, so a checksum makes more sense.

For matching the JavaScript to the sourcemap, I don't think we'd want to
require an official UUID, but rather any unique identifier generated in a
way that mismatches are unlikely. (For a build system that requires its
output to be a deterministic function of its input, we would want to use a
checksum of some sort.)

Perhaps put the scheme in front:

//# sourceMapId=sha1:3da541559918a808c2402bba5012f6c60b27661c

//# sourceMapId=uuid:db99a770-f281-11e3-ac10-0800200c9a66

This looks suspiciously like a URN so maybe we could just use that:

On Thu, Jun 12, 2014 at 3:09 PM, Andy Sterland 

> I think the main reason I was leaning away from the embedded identifier
> approach is that one of the scenarios where the feature needs to work is
> when the generated JS file has no source map comments. That enables
> developers debugging production sites that strip comments to use source
> maps still. Take for example jQuery which now removes the sourceMappingURL
> comment from the minified jQuery file.

The jQuery file is here:

They have a comment at the top, so it seems they're not opposed to all

In the release notes [1], they say: "If you want to use the map file for
debugging the minified code, copy the minified file and add a //#
sourceMappingURL comment to the end of the file."

So they're aware of the issue and they could have kept the sourceMappingURL
comment if they wanted to, but decided it was better to make the developer
do it.

We would have to ask them why they took it out, but I would guess that one
issue is that it's unclear where the URL should point to avoid a broken
link. (Absolute versus relative URL, and so on.) This wouldn't be an issue
with a URN, so maybe they'd be fine with leaving it in?

- Brian