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
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.
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
>> (Not sure if convention on the group is for inline commenting or top
> 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
> "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
> 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