From:  "Fitzgerald, Nick" <nfitzgerald@mozilla.com>
Date:  03 Jun 2014 08:22:55 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.js-sourcemap
Subject:  

Re: Adding media type for sources to source maps

NNTP-Posting-Host:  63.245.216.66

We talked about this a while back: 
https://groups.google.com/d/msg/mozilla.dev.js-sourcemap/bZGz99CsN6I/5UiGQ3v69RoJ

What I like about your proposal is that its backwards compatible, 
because it feels too late to mess with the sourcesContent.

Overall I like it! I've added a couple notes inline below.

Also, sorry to begin the bikeshedding, but I'd like to propose that we 
name the new property "sourcesMediaType" which is in the same vein as 
"sourcesContent" for adding more info to the "sources" property. Nice to 
be consistent, right? :)

On 6/2/14, 4:01 PM, Andy Sterland wrote:
> For the case where there is only one source language the value of the x_ms_mediaTypes property is an array with only one string defining a media type for all the source files. The string itself should be a media type as defined by RFC6838. As there really isn't an exhaustive list of media types it's really an opaque string between source map producers and consumers but ideally producers should document their media type.

So you're saying that the one media type would apply for all sources? 
That works well when you have only one media type, but what about when 
you have a bunch of typescript files and one js file? It seems like it 
would be more general to define that this media type is for the first n 
sources, this media type for the second m sources... etc. Something like:

```
sources: ["a.ts", "b.ts", "c.ts", "d.js"],
sourcesMediaType: [
   [3, "application/x.typescript;version=1.0.3.0"],
   [1, "application/javascript"]
]
```

The other benefit of this approach is that there is no magical 
distinction between a length 1 list of media types and a length > 1 list 
of media types.

Not married to that specific form of [n, "some/mediaType"], but think 
that the idea of generalizing + unifying the use cases is valuable.

> We're looking at adding this in both the TypeScript compiler and the F12 debugger in IE and would love to get feedback from everyone as it seems like it would be useful for all.

It would be nice to come to an agreement and properly add this in the 
spec before you guys ship it as an extension, since this is something 
we've expressed interest in before :)

Nick