Source map Simple format proposal

[simon....@gmail.com]

I've worked with source maps for a few years now. I've contributed to several compilers and worked with source map issues on them, such as [reworkcss/css], [postcss] and [CoffeeScript]. I've also contributed to [mozilla/source-map].

I've thought a long time about proposing an alternate, human readable format to complement today's (version 3) format. You can read all about it here:

https://gist.github.com/lydell/a391bc1d01b2bfd52004

The above link also contains real-world testing and practical examples of the proposed format.

I'd love to hear somebody else's opinions, thoughts and feelings on this!

[reworkcss/css]: https://github.com/reworkcss/css/
[postcss]: https://github.com/postcss/postcss/
[CoffeeScript]: http://coffeescript.org/
[mozilla/source-map]: https://github.com/mozilla/source-map/

[Joey Schorr]

A blast from the past!

This is similar in design to version 1 of Source Maps, which I prototyped
at Google in 2009. You can still see the original "parsing" code here:
https://code.google.com/p/closure-inspector/source/browse/trunk/chrome/content/inspector/sourcemap.js#136

We moved away from doing so not only because of file size concerns, but
performance as well. At the time, pulling the entire JSON object at load
time into memory was less efficient than having a string, even if we had to
parse the string to find column positions. We actually had separate JSON
objects on each textual line as a way to partly alleviate the "load entire
contents" issue.

I imagine that these concerns are somewhat still valid for extremely large
maps, but far less so today where JSON parsers are far more optimized. It
might be worth adding some benchmarks of parsing the JSON-only format vs
the current version 3 format.

Thanks,
Joey Schorr

> _______________________________________________
> dev-js-sourcemap mailing list
> dev-js-s...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-js-sourcemap
>

[Nick Fitzgerald]

We regularly encounter source maps around 15-20 megabytes in the wild and
parsing is often a performance bottleneck. Emscripten's source maps are
often gigabytes large, rendering them mostly useless. Blowing that up by
3-4x isn't a practical option, IMO.

I'd rather go the other way: "pull a wasm" on source maps and create an
equivalent-but-more-space-efficient binary format.

The data URI hack is just that: a hack. If we had a better option, we would
jump on it.

That said, sokra's visualization tool is pretty great. If there was serious
interest in "pulling a wasm" on the source map format, it would be very
worthwhile to invest further in such tools.