Re: Source Map v3 Proposal - sourcesContent questions

[John Lenz]

+dev-js-s...@lists.mozilla.org

On Tue, Apr 2, 2013 at 6:57 PM, Joseph Pecoraro <peco...@apple.com> wrote:

> Hey,
>
> I see you are both the editors of the Source Map Revision 3 Proposal spec
> at:
> <
> https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit
> >
>
> 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
it.


> - Joe
>

[Fitzgerald, Nick]

On 4/3/13 10:32 AM, John Lenz wrote:
> +dev-js-s...@lists.mozilla.org
>
> On Tue, Apr 2, 2013 at 6:57 PM, Joseph Pecoraro <peco...@apple.com> wrote:
>
>> Hey,
>>
>> I see you are both the editors of the Source Map Revision 3 Proposal spec
>> at:
>> <
>> https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit
>> Comments are disabled, so I'm sending an email.

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

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 (https://github.com/mozilla/source-map).

Nick