From:  Brian Slesinsky <>
Date:  10 Jun 2014 14:34:01 Hong Kong Time

Re: Adding checksums to source maps


On Mon, Jun 9, 2014 at 10:23 PM, Andy Sterland 

>  (Not sure if convention on the group is for inline commenting or top
> posting...)

I don't think we have any particular convention yet? I'm not consistent
about it.

 Re: Checksum in file
> Having the checksum in the URL would help validate that a source map is
> for that file but I think we’d still need something to verify that the
> sources are for the source map.

To clarify, I was thinking of a checksum as an alternative to a URL, rather
than part of it. The debugger could ignore a given URL and generate its own
(perhaps to a private server) that includes the checksum, or perhaps the
debugger wouldn't even use HTTP(S) to fetch the sourcemap. But if the
debugger does use the given URL, it would probably make sense to pass the
checksum as well, perhaps as a query parameter or HTTP header. (Since the
debugger doesn't actually need to do any checksum calculation but just
hands back what it was given, it's actually more of an opaque token in this

On the other hand, it would also make sense to use the checksum for its
original purpose (detecting corrupted data). I think we might want to
checksum just the JavaScript lines that are actually included in the
"mappings" field, not including trailing blanks or line endings, and
perhaps use a different line separator like a pipe when computing the
checksum. Having the actual checksum as well at the end of the file might
be useful since the debugger could detect file corruption without even
doing a sourcemap lookup. It also makes it easier to detect
interoperability bugs where the compiler and debugger disagree about how to
calculate a checksum.

I didn't comment on the checksums for the source files because I'm okay
with that part. (The checksum points in the same direction as the URL, so
it would already serve as an alternative lookup mechanism.)

Though for our scenarios I think we still need to have something that is
> encapsulated in the source map. A solution that requires the developer to
> ship the comment at the end of the file would lock out developers who need
> to debug in cases where they can’t have comments in the file (say on a
> production server with comments stripped).

I don't understand this use case yet. If they strip comments, that changes
both the sourcemap and the checksum, right? It seems like a JavaScript
minimizer has to generate a new sourcemap anyway, in which case it could
also calculate a new checksum and add a new comment.

Also, putting in a checksum doesn't reveal any information that you don't
already have (unless there is file corruption), so it seems safe to leave
it in?

> Re: Unrelated files
> By unrelated I meant that an sourcemap chosen by a developer from the
> debugger may not be for the generated file or the source file. In the case
> of the generated file an example of where it would be broken is if the
> developer picked the sourcemap for a different version of the generated
> file. In the case of source files the most common broken, unrelated, use
> case is also likely to be mismatched versions. For example if the developer
> updated the generated file on the server but not the source files the
> relative paths might all resolve and files would be fetched but the source
> files wouldn’t match the actual source files. In both cases if the files
> don’t match it can be a very subtle issue for a developer to spot thus the
> need to programmatically verify the symbols are for the right files.

Okay, I misunderstood that part. I was thinking more about automatically
finding the right file rather than asking the developer to do it and
detecting mismatches.

- Brian