From:  John Lenz <>
Date:  04 Apr 2013 01:32:09 Hong Kong Time

Re: Source Map v3 Proposal - sourcesContent questions


On Tue, Apr 2, 2013 at 6:57 PM, Joseph Pecoraro  wrote:

> Hey,
> I see you are both the editors of the Source Map Revision 3 Proposal spec
> at:
> <
> >
> Comments are disabled, so I'm sending an email.
> There was a recent addition of "sourcesContent" to the spec. Although the
> spec doesn't go into detail, it sounds like sourcesContent values are
> either null, or strings containing source text. It seems like that has a
> few drawbacks:
> 1. It makes it difficult for SourceMap consumers to determine the MIME
> type of the content. Is it JavaScript? CoffeeScript? Something else
> entirely?
> 2. What if an input was not text? Admittedly SourceMaps don't deal with
> binary files in general because it doesn't work with line # conversions,
> but if a resources is generated with a binary file and the binary file is
> listed in the sources list then consumers / debuggers typically fetch it
> anyways.
> Without sourcesContent, consumers normally make a request (HTTP GET) for
> the source via its resolved URL, and would get MIME type information for
> the resource from the HTTP response.

IF the source is available via HTTP there is no need for sourcesContent.

>  Now, with sourcesContent it seems consumers would need to look at the
> file extension of the associated name in the sources list, or make a fuzzy
> determination by scanning the contents. Neither are ideal.

> If sourcesContent contents were data URIs, they could contain the mime
> type and contents, e.g. "data:text/javascript,...". I'm open to other
> suggestions as well, this just seems like a simple, potentially backwards
> compatible, change that could be made to the spec and benefit generators
> and consumers of SourceMaps.

It seems fragile to have to detect a data URI in place of text.

> Is there any desire to improve this portion of the spec? What would need
> to be done to get consensus and make an improvement along these lines?
Sure.  The end-goal for source maps is to enable tooling for javascript.
 And it is well suited for JS-to-JS translations but for non-JS languages,
there is a lot missing.  The Google Web Toolkit team would like to see
support for identifying heap object.  I've desire "scope" identification.
Microsoft has indicated a desire for source file checksums, etc.  But two
things need to happen (1) there needs to be a concrete proposal (2) the
implementing browser vendors (currently Chrome) need to agree to implement

> - Joe