Support source maps

[TomiBelan]

Cool project! I really like how readable the generated code is (especially compared to Streamline, Tame etc). It'd be nice if it also supported source maps. Those are files that map locations in the source to locations in the generated code to make debugging easier.

Escodegen already supports source maps, so most of the hard work should hopefully be already done. But when the parser converts the AST nodes using syntax.factory, their "loc" property is lost. They need to keep it for source maps to work. (As for new nodes that weren't in the original AST, I guess their "loc" should just be null.)

Perhaps that's the only required change (well, plus adding the CLI option itself), but I'm not sure.

[BYVoid]

Thank you for your solution. It is scheduled to support source maps.

[BYVoid]

@TomiBelan Source map is supported experimentally. You could have a try using command below:

continuation script.js -o compiled.js

A file named compiled.js.map will be generated and //@ sourceMappingURL=compiled.js.map will be appended to compiled.js

[TomiBelan]

That was fast! Looks like it's working. I had to deal with some Chrome/Webkit issues though... (For instance, console logs that happen during page load still show the compiled location. I thought it's a continuation.js issue, but when I put it in an onclick handler it started working...)

It'd be nice if the implementation didn't use a global variable. I think it'd be better API design to return both the code and the source map from compile() (perhaps only when options.sourceMap is true, if you care about API compatibility at this stage).

It's a pity that the "Generated by..." mark had to be moved to the bottom. I'm looking into whether escodegen can be convinced to put it on top.

[TomiBelan]

As for avoiding the global variable and returning both code and source map: for instance, escodegen has an undocumented option "sourceMapWithCode" which makes the return value be { code: "the generated code", map: "the map" }. It might make sense to adopt the same output format, and perhaps even use that option directly (though that depends on what extra stuff continuation.js is doing with the source map).

Escodegen (and source-map) doesn't seem to support line offsets or comments on top, unfortunately. The toStringWithSourceMap() function always counts from line 1.