Source maps (was: Multiline Strings)

Nick Fitzgerald fitzgen at
Fri Mar 14 15:02:53 PDT 2014

I'm not married to the AST format I proposed.

I do feel very strongly that each language targeting JS shouldn't have
to write a browser devtools extension for every browser its users want
to debug.

I feel very strongly that users debugging their sources that were
compiled to js should be able to set watch expressions and conditional
breakpoints in their source language.

I feel very strongly that users should be able to inspect their
program's environment and bindings whether or not those bindings have
been compiled into JS variables or into an index in a typed array.

I feel very strongly that users should be able to inspect their values
and data types directly rather than the implementation of those data
types when compiled to JS. (Imagine using GDB and only printing binary
blobs instead of a nice printout of a struct and its slot names and
corresponding values).

Perhaps not all of that belongs in the debug format, but the
functionality should be exposed somehow.

One thing I tried to stress about the importance of an extensible
format was that it would be easy for compilers to progressively add
more debugging information to the "source maps" they generated. If the
compiler should decide that it will only ever do source location
mapping, that would be fine as well.


On Thu, Mar 13, 2014 at 7:20 AM, David Nolen <dnolen.lists at> wrote:
> As the maintainer of the ClojureScript compiler this doesn't sound like much
> of a simplification. The sum total of source map support in ClojureScript is
> < 400 lines of Clojure. To support what's being proposed would add a
> significant amount of complexity for something we don't care about at all -
> the JavaScript AST. We currently rely entirely on the Google Closure
> Compiler for the final pass as it offers best of class minification,
> optimization, and dead code elimination.
> A source map format based on annotating a JS AST seems to introduce a lot of
> complexity once you start thinking about how this information will be
> preserved over multiple stages of minification, optimization, and dead code
> elimination.
> Some of your suggestions also seem to me to be best handled by other means
> and don't belong in a source map proposal at all - REPL support and
> printing/presentation of language objects.
> FWIW, the ClojureScript community has completely embraced the existing
> source map technology. Some of the issues raised like scope we find to be
> minor issues that don't really impeded effective debugging as we try to
> avoid renaming and unclear munging as much as possible.
> Honestly the two things we really want - REPL support and printing of
> ClojureScript objects could easily be addressed by providing appropriate
> simple hooks into the dev tools offered by a browser vendor. To have to
> bother with generating and annotating JS ASTs to achieve these two things
> just sounds like pointless work.
> David
> On Wed, Mar 12, 2014 at 5:00 PM, Nick Fitzgerald <fitzgen at> wrote:
>> > 4) Browsers are still all over the place in how they report Error stack
>> > trace information.
>> We (Firefox Developer Tools) purposefully don't expose source mapped
>> stacks to the web because it would require adding some kind of API to
>> know when source maps are done being fetched or blocking(!) on
>> Error.prototype.stack until the source map is fetched. We also avoid
>> fetching source maps unless the debugger is open, so this would expose
>> to the web if the debugger is open. Furthermore, we wouldn't want to
>> only have the source mapped stack, you would also want the plain JS
>> stack if you think that the source map could be bogus or if you are
>> debugging the source maps you are generating as a tool author. This
>> would further complicate the stack string.
>> > 1) There is not yet a standard for sourcemaps. But see
>> > <>,
>> >
>> > <>,
>> > and <>. Would someone care to
>> > champion this for inclusion
>> > in ES7?
>> If a debug format for targeting JavaScript were to be standardized, it
>> should do more than simply file/line/column translation. My thoughts
>> on this subject outgrew an email reply, so I have collected them here:
>> _Nick_
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at

More information about the es-discuss mailing list