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