repl: add experimental TypeScript support

[avivkeller]

Adds experimental TypeScript support to the REPL, opt-in-able via the --experimental-repl-typescript flag.

[nodejs-github-bot]

Review requested:

• @nodejs/config
• @nodejs/loaders

[Renegade334]

This is going to cause problems with multiline, I suspect.

Concise example:

const regexps = new Set<
  RegExp
>();

If typed as multiline input to REPL, it's going to consider the statement complete after the second newline, as it's a valid JS statement, and evaluate new Set < RegExp, which evaluates to true. I don't know that there's any way around these sorts of parsing conflicts.

[marco-ippolito]

It should be handled exactly like we handle the -e and -p. If it's valid js treat it as such otherwise fallback on TS

[codecov]

Codecov Report

❌ Patch coverage is 65.21739% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.17%. Comparing base (c8e2a82) to head (cf6ff9f).

Files with missing lines	Patch %	Lines
lib/internal/repl/eval.js	61.90%	8 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #64077      +/-   ##
==========================================
+ Coverage   90.16%   90.17%   +0.01%     
==========================================
  Files         746      746              
  Lines      242760   242781      +21     
  Branches    45765    45764       -1     
==========================================
+ Hits       218875   218931      +56     
+ Misses      15375    15335      -40     
- Partials     8510     8515       +5     

Files with missing lines	Coverage Δ
src/node_options.cc	76.62% <100.00%> (-0.08%)	⬇️
src/node_options.h	97.52% <100.00%> (-0.49%)	⬇️
lib/internal/repl/eval.js	90.51% <61.90%> (-2.65%)	⬇️

... and 33 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[avivkeller]

cc @nodejs/typescript

[Renegade334]

It should be handled exactly like we handle the -e and -p. If it's valid js treat it as such otherwise fallback on TS

It's not a blocking concern per se, but I do think that this has the potential to be really quite a UX tripwire. For example, pretty much any use of function template parameters hits this (a<b>(x) is going to be executed as (a < b) > x rather than a(x)), which may match the current behaviour of -e, but I would say is really not what users are going to expect in a REPL environment when explicitly enabling TypeScript mode.

The alternative would be to make TS an explicit on-off repl flag, ie. parse REPL input like it were in a .ts module if the flag is enabled, and unconditionally pass it through Amaro, without speculatively parsing it as JS first.

There is also a subtle difference between REPL and -e, because whereas -e will attempt to evaluate the entire input and fallback if needed, REPL input will be evaluated on a line-by-line basis, multiline REPL input will attempt to evaluate a partial input and potentially tokenize it very differently depending on where the newlines fall (hence the multiline template parameter case above, which -e would handle just fine).

[marco-ippolito]

In the -e you can pass a flag to force the evaluation as module ts or common js ts to disambiguate. In a future where ts support is mixed with js and not behind a flag, js should always be evaluated first

[jasnell]

I'm not convinced this is the best way to handle this. What might be better is a new REPL command similar to .editor ... something like...

> .typescript
// Entering TypeScript mode (Ctrl+D to finish, Ctrl+C to cancel)
const regexps = new Set<
  RegExp
>();
^D

The otherwise regular behavior of the repl remains untouched.

To cover -e style usage, something like a new -t option can be added:

$ node -pt "const regexps = new Set<RegExp>();"

[targos]

There is also a subtle difference between REPL and -e, because whereas -e will attempt to evaluate the entire input and fallback if needed, REPL input will be evaluated on a line-by-line basis, multiline REPL input will attempt to evaluate a partial input and potentially tokenize it very differently depending on where the newlines fall (hence the multiline template parameter case above, which -e would handle just fine).

@Renegade334 I suppose this is mostly a concern for people copy-pasting multiline inputs into the REPL. That may be solvable by supporting paste bracket mode (87af913).

[Renegade334]

There are other subtleties here specific to strip mode and partial/multiline input, even without any TS syntax present.

For example, function foo() is not deemed a valid statement by acorn and fails isValidSyntax(), but throws a recoverable error on evaluation and therefore currently triggers a multiline continuation. However, it's stripped by swc to pure whitespace, so after this change, the line will be discarded completely.

If we stick with the "speculatively type-strip line-by-line on an invalid JS parse" model then it's worth pointing out that previously valid multiline JS could now do weird things.

[avivkeller]

In the -e you can pass a flag to force the evaluation as module ts or common js ts to disambiguate. In a future where ts support is mixed with js and not behind a flag, js should always be evaluated first

Would everyone be fine with TypeScript being, as @Renegade334 said, opt-in, not attempt to be JS and fallback?

[avivkeller]

Bump on my question above :-)?

[mcollina]

In the -e you can pass a flag to force the evaluation as module ts or common js ts to disambiguate. In a future where ts support is mixed with js and not behind a flag, js should always be evaluated first

Would everyone be fine with TypeScript being, as @Renegade334 said, opt-in, not attempt to be JS and fallback?

yes

[Renegade334]

Don't believe this holds true with the change.

[Renegade334]

From a multiline perspective, this approach will still only allow multiline input to be pure JS, as SWC InvalidSyntax errors will leave the input untransformed, and input containing TS-only syntax will then fail both JS execution and the Acorn recoverable parsing test.

// Triggers multiline continuation
function foo(

// Triggers "uncaught SyntaxError"
function bar<T>(

The inconsistency would be really jarring, and I wonder if we need to just disable multiline in TS mode, and explicitly signpost users to .editor.

Alternatively, we could try and identify recoverable SWC InvalidSyntax errors from the initial strip attempt, but this would still have some inconsistencies with JS multiline. Truly unparseable partial input usually errors in SWC with some flavour of "unexpected eof", but there are cases like const baz: string whose "stripped" JS equivalents are considered recoverable, but which SWC doesn't report in this way.