We talked about this a while back:
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"],
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 :)