fix TLA with esnext syntax

[caub]

currently n> class A{x=1} await 1 fails, because acorn doesn't handle esnext syntax, I could have used npm.im/acorn-stage3, but acorn-walk doesn't work with those stage3 new nodes, so I went full babel

[ljharb]

The entire point of n> is to use no babel and match node exactly.

[ljharb]

TLA shouldn’t even work in n> until it’s shipped in node.

[caub]

I see your point, but we are talking about a bot CLI, which has to be practical, just like devtools, or node --experimental-repl-await similarly have this, and other convenience helpers, it doesn't intend to be a real TLA at all

[ljharb]

Fair. I still think it’s best to avoid Babel for this mode.

[brigand]

I think it's fine to support TLA, but only if we avoid running code that doesn't use TLA through babel.

Base babel settings: all syntax plugins enabled

ON_RECEIVE_MESSAGE

1. Set toExecute to the provided code
2. search for /\bawait\b/ in toExecute. If not found, go to NODE
3. attempt to parse with babel, producing an AST. If failed, go to NODE
4. attempt to find a TLA, and if not found go to NODE
5. do the babel transform for TLA, if successful then set toExecute to the resulting code
6. go to NODE

NODE:

1. Execute toExecute as you normally would with the n> command.

[caub]

to be clear, I switched from acorn to babel-parser and enabled all syntax plugins (but you're right we don't need all) because I wanted to be able to parse all currently valid code for n> like class A { x = 1; },

current node (12.9.0) supports those:

    'bigInt',
    'classProperties',
    'classPrivateProperties',
    'classPrivateMethods',
    'numericSeparator',
    'optionalCatchBinding',

Enabling all of them doesn't mean n> can suddenly evaluate optional-chaining etc.., no it'll just allow to parse it, and processTLA then stringify it and pass it to the run.js script with mode 'n' where optional-chaining would fail

• input: await 1
• processTopLevelAwait transforms in: (async() => { return await 1 })()
• run.js evaluates (async() => { return await 1 })() with given mode ('b', 'n', 'e')

In case of b> babel mode, we're sort of parsing twice the same code, is it what you want to improve @brigand?

note: I'd really want to avoid using regex for code, it'll fail for some cases let s = "test await 1"

hmm I guess the answer is yes to my previous question @brigand , we can just remove step2, and use babel-parser to detect if the AwaitExpression exists at the top level, I'll work on that

[brigand]

In the steps I outlined, the 'await' regex is just to quickly skip the following steps for code that we are sure doesn't have a top level await.

[caub]

@brigand Ok done in the last commit, in comparison this is a simpler approach caub/jellobot@fix-tla...caub:fix-tla2 but that parse twice if babel+TLA, so let's use your idea, thanks