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 <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
