From:  Conrad Irwin <>
Date:  10 Jun 2014 15:21:57 Hong Kong Time

Re: Adding checksums to source maps


I like this idea in general, but am ambivalent about the proposal in
its current form. At Bugsnag we also want a mechanism for identifying
which source-maps go with which minified code, without the developer
making the source-map public.

The problem is equivalent to the problem that iPhone developers have
for debug symbols in iPhone apps. The app (equivalent to the minified
javascript) has a dSYM (equivalent to the sourcemap) with all the
debug information. To tell whether they are related, they both contain
a UUID. If the UUIDs match, you know you are looking at the right
thing. The nice thing about Apple's approach is that I don't have to
know how they implement the UUID (it turns out it's an MD5 of the text
section of the binary, so I could calculate it if I wanted), all I
have to do is compare two strings.

Is there anywhere in the minified javascript you could put the hash/uuid?

Ideally a comment like // @sourceMappingUUID= that post-processing
steps could be instructed to preserve. (There's no downside to
publishing a hash/uuid of the code). This has the doubly-nice property
that a developer can use the search feature of their laptop's
hard-drive to find the source-map given the dSYM.

I also fail to see the need for also hashing the sources, I guess
that's a separate problem where you want to be able to recover from
the build tools inserting a bogus sourceRoot?


On Mon, Jun 9, 2014 at 11:34 PM, Brian Slesinsky  wrote:
> On Mon, Jun 9, 2014 at 10:23 PM, Andy Sterland 
> wrote:
>>  (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
> scenario.)
> 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
> _______________________________________________
> dev-js-sourcemap mailing list