I think "sourcesDefaultMediaType" and "sourcesMediaType" rather than
overloading sourcesMediaType. As these are optional, generally useful, and
we can add them without changing the meaning of any existing source maps,
we can add this to the spec without problem. As long as we can agree on
Regarding size, Brian and Google Web Toolkit team have been pretty
successful in reducing the size of the source maps by removing information
that isn't useful to the debuggers (reducing them to basically line
mappings rather than token maps). This is controlled by the source map
producer but can be done as a post-process. But that is a discussion for
If we do add this, I would like to document common "known" media types in
the spec appendix (CSS,HTML,JS,CoffeeScript,TypeScript,SASS,etc) to reduce
the ambiguity that naturally comes along with using media types.
On Tue, Jun 3, 2014 at 9:16 AM, Fitzgerald, Nick
> On 6/2/14, 5:57 PM, Brian Slesinsky wrote:
>> This seems slightly less straightforward since there's more room for
>> calculating the index wrong while reading or writing it, compared to a
>> parallel array.
> Less straightforward, but its consistent.
>> I'm not sure we need to worry about the size of the parallel array.
>> Sorting the source files by language might be a good idea if it compresses
>> better, but even without that, we're talking about two characters per
>> source file (assuming fewer than 10 languages). If you do sort it,
>> repeating the same number is going to compress very well. So perhaps better
>> to stick with the more straightforward parallel array and let gzip handle
>> Having a special case for when every source file is the same language
>> seems useful mostly for readability, since a list of all zeros would
>> compress well too. A slightly more general rule would be to extend the
>> parallel array with zeros if it's shorter than the list of source files.
>> You could put your most commonly used language at the end (with index 0)
>> and have a pretty short list of mappings. But perhaps that's more confusing
>> than readable.
> I was mostly concerned with removing the special case and making it
> consistent across various scenarios because relying on the length of the
> array doesn't feel elegant to me.
> Relying on gzip is fine for the network, but source maps can get pretty
> large on disk, which is frustrating as well. David Nolen was just
> expressing this to me at JSConf.
> The more I think it over, though, the less the special case is bothering
> me, now.
> Another option would be to separate the media types from the parallel
> array of media types for specific sources. We could VLQ the parallel array
> as relative indices into the list of all media types. You know, the same
> thing we do in the rest of source maps ;)
> sources: ["a.ts", "b.ts", "c.ts", "d.js"],
> sourcesMediaType: "CAAD", // 1, 0, 0, -1
> What do you guys think of this? I like it because it is consistent without
> special cases, compresses both all-one-media-type and mostly-one-media-type
> pretty well, and fits with the way we do things in source maps already.
> dev-js-sourcemap mailing list