Source maps (was: Multiline Strings)

[David Nolen]

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 gmail.com> 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 <
> https://docs.google.com/a/google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k
> >,
> > <
> https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#source-maps
> >,
> > and <https://github.com/mozilla/source-map/>. 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:
>  http://fitzgeraldnick.com/weblog/55/
>
> _Nick_
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140313/4bf31af1/attachment.html>