From:  "Fitzgerald, Nick" <>
Date:  04 Apr 2013 04:43:58 Hong Kong Time

Re: Source Map v3 Proposal - sourcesContent questions


On 4/3/13 10:32 AM, John Lenz wrote:
> 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.

I will add a link the mailing list to the top of the spec.

>> 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.

That does seem fragile. I would prefer something like have the sources 
be objects rather than strings and there could be "content" and 
"contentType" properties on each source object.

>> 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
> it.
Correct, although I would add one nit: it isn't *only* browser vendors 
that need to implement it but the libraries used by the compilers that 
generate source maps as well (