Support let/const block binding via https://github.com/olov/defs about regenerator

[benjamn]

https://github.com/olov/defs seems like a great suggestion, thanks!

[termi]

I can do it. But there is a problem - defs uses non-harmony esprima so it's fails with error on trying to parse code with generator.

[olov]

Hi! I'll be happy to help out in making sure that defs can be used in the best way possible together with es6-transpiler. defs is usable both as a command-line tool and as an API - see the README for more info.

How would you like to integrate it with regenerator? One option is just to let regenerator spit out code with const and let intact, and then feed that code directly into defs. If regenerator currently changes const and let to var's (without sufficient analysis and transformation) then that's not kosher es6 and thus leaving const and let intact is the better thing to do, so that end-users at least have the option of running it through defs.

To minimize overhead, it's certainly possible to integrate it deeper with defs in a way where you hand off your transformed AST to defs and it does further transformations, and you can then just decompile the AST with escodegen. Even though defs works hard to do do minimal alterations of the input source code, it simultaneously transforms the AST so everything is already in place to handle this mode of operation, save for a configuration parameter or two (which I'll be happy to add).

In either case, I'd be glad if you'll be able to use defs as a dependency instead of a fork, so that we get maximum benefit upstream.

[benjamn]

Hi @olov! How would you feel about exposing an interface to defs that takes an AST (rather than a string of source code), transforms it, and returns the transformed AST? That would remove the dependency on specific esprima versions, I think, and allow regenerator to use defs to convert all let and const declarations to var declarations before hoisting declarations (see https://github.com/facebook/regenerator/blob/master/lib/hoist.js). To be clear, since regenerator relies on hoisting all declarations into the outer function scope (so only assignments remain in the inner function), I think the easiest path is to convert everything to vars and then let regenerator pick up after that conversion.

As a side-note, regenerator currently uses https://github.com/benjamn/recast to reprint ASTs with minimal alterations (that's the whole point of recast), so escodegen should not be necessary.

[olov]

I think allowing an AST as input to defs is the way to go. AST output support is already there so we're set with that.

As for pipeline order defs -> regenerator vs regenerator -> defs, I guess that boils down to where to add any extra code and if I understand you correctly it would require a substantial code effort from your side to have regenerator run first? If so let's go with defs first. defs currently relies on receiving a pure ES5 + constlet AST, so it could have some issues with receiving an AST with generators although I'm pretty sure that we should be able to resolve any of such issues pretty easily. I'll do the first minimal changes for this in a new branch for you to try out.

[termi]

@benjamn There is also need to be an option to not to calling defs. In my case (in es6-transpiler) I already translated let/const by using defs before calling regenerator.

[olov]

So with olov/defs@1f0a9e9 defs will accept an AST as input. The only extra analysis added is that it takes yield expressions into account when deciding whether it can transform a loop closure into an IIFE or not. Let me know if there are any issues!

[olov]

@termi yeah, that can either be done with an explicit regenerator option or perhaps more easily (and robustly) by having regenerator walk the AST once and detect whether there are any constlets in there. Iff so, defs is called.

[olov]

In particular, if regenerator is to support anything else than function* and yield (let me know if it already does), say like for-of, then defs need to do so too (in particular in its analysis phase) or else the constlet transformation will be buggy.

[termi]

I see no one's done this yet. I will start doing this right now. Sorry for delay - I am in hospital now and very sick.

[termi]

@benjamn There is a problem with recast.parse: neither defs nor ast-types doesn't work with File-node wrapper from recast parser. So I have to do something like this:

var recastAst = recast.parse(source, recastOptions);
var ast = recastAst.program;

ast = defs(ast, { ast: true }).ast;

recastAst.program = transform(ast);
recast.print(recastAst, recastOptions);

[olov]

@termi just a minor comment on that example (not answering the problem you're having).

Instead of doing ast = defs(ast, { ast: true }).ast; you can just do defs(ast, { ast: true });. defs manipulates the AST it receives without copying it first.

[termi]

@olov It's quite logical! Thx. BTW, make sure you have a latest version of defs in npm.

[olov]

I've been waiting with releasing defs 0.6.0 to make sure we have everything in place for what's needed for regenerator first (don't want to break API immediately after). Once I hear ACK I'll release!

[benjamn]

@termi that seems like a reasonable way to handle the File node type. Sorry for the confusion!

[termi]

@olov I guess that's all. You may now release defs 0.6.0

[olov]

defs 0.6.0 released