templates evaluate at global scope, breaks statement`return;` about jscodeshift

[cpojer]

you can also use ast-types to build up your return statement.

j.returnStatement();

See https://github.com/benjamn/ast-types/blob/master/def/core.js#L106

[fkling]

FWIW

expression`return;`

would never work anyway, since a return statement is not an expression. but

statement`return;`

has the same problem.

[fkling]

But yeah, in same cases it might just be easier to mix and match. E.g. instead of

statement`return foo(${someNode});`

you could write

j.returnStatement(expression`foo(${someNode})`)

[pieterv]

Sorry yes, statement not expression.

Yeah i have been mixing and matching but this:

statements`
var aasd = () => 'some complex stuff';
${j.returnStatement(expression`aasd(${someNode})`)}
`;

Is considerably less readable than this:

statements`
var aasd = () => 'some complex stuff';
return aasd(${someNode});
`;

I understand this is a hard problem to solve but i do think having a solution in the future will be helpful since it reduces the complexity of the code which is valuable as the transforms get more complex.

[cpojer]

I think we could potentially do this: try to parse it in the global scope. If that throws, try to parse it wrapped in a function and pull it out.

It seems a lot like

var div = document.createElement('div');
div.innerHTML = text;
var myElement = div.childNodes[0];

:D

[pieterv]

Yeah that seems like it might work, i was wondering if there was a away to inform template what context it should run in by passing it a path or something.

[fkling]

yeah, the above solution would't work for things like break.

[fkling]

Maybe we can have a type passed as context. E.g.

statement.in(j.IfStatement)`break;`

it's a bit magical because the implication would be that the code is evaluated in the body of an if statement and it wouldn't work for all types, but it may be the most concise way.

---

Potentially supported types:

• Function
• IfStatement
• ForStatement, ForInStatement, WhileStatement, DoWhileStatement, ForOfStatement
• SwitchStatement
• SwitchCase

Of course we could also just provide these as convenient functions so that becomes a bit less magical (from the API side):

• statement.inFunction
• statement.inIf
• statement.inLoop (all the loops are essentially the same)
• statement.inSwitch
• statement.inSwitchCase (it only really supports break, but is very different from other contexts)

[pieterv]

I was just writing out the same suggestion! :P I think it will work, like you said we will need to manually code the cases but it shouldn't be to much overhead.