module: support eval with ts syntax detection

[marco-ippolito]

Refs: nodejs/typescript#17
Previous attempt: #56273

What is the problem?

Before this PR when --experimental-strip-types was enabled, --eval would always parse the input as typescript.
If unflagged, the typescript parser would throw different errors on invalid syntax so unflagging would become a breaking change.

With this PR when running --eval and --experimental-strip-types is enabled, if parsing the code fails we try again with typescript parser.
If it fails again we throw the original error, adding the typescript parser message.

In this way the error is the original error and it's not a breaking change.

Example:

With `--experimental-strip-types`:


marcoippolito@marcos-MBP node % ./node --experimental-strip-types -e "enum Foo{}"    
file:///Users/marcoippolito/Documents/projects/forks/node/[eval1]:1
enum Foo{}
^^^^

  x TypeScript enum is not supported in strip-only mode
   ,----
 1 | enum Foo{}
   : ^^^^^^^^^^
   `----


SyntaxError: Unexpected reserved word
    at compileSourceTextModule (node:internal/modules/esm/utils:338:16)
    at ModuleLoader.eval (node:internal/modules/esm/loader:218:18)
    at node:internal/process/execution:322:29
    at asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:98:11)
    at Object.runEntryPointWithESMLoader (node:internal/modules/run_main:120:19)
    at evalTypeScriptModuleEntryPoint (node:internal/process/execution:318:47)
    at node:internal/main/eval_string:32:3

Node.js v24.0.0-pre




Without `--experimental-strip-types`:


marcoippolito@marcos-MBP node % ./node  -e "enum Foo{}"
file:///Users/marcoippolito/Documents/projects/forks/node/[eval1]:1
enum Foo{}
^^^^

SyntaxError: Unexpected reserved word
    at compileSourceTextModule (node:internal/modules/esm/utils:338:16)
    at ModuleLoader.eval (node:internal/modules/esm/loader:218:18)
    at node:internal/process/execution:73:24
    at asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:98:11)
    at Object.runEntryPointWithESMLoader (node:internal/modules/run_main:120:19)
    at evalModuleEntryPoint (node:internal/process/execution:72:47)
    at evalTypeScriptModuleEntryPoint (node:internal/process/execution:309:12)
    at node:internal/main/eval_string:32:3

Node.js v24.0.0-pre

This PR also add two new --input-type:

• module-typescript
• commonjs-typescript

So that if the syntax is known we can reduce the overhead of multiple parsing.
If the -typescript input is passed we can throw ERR_INVALID_TYPESCRIPT_SYNTAX safely

the temporary side effect is to remove the workers ability to eval typescript code, which is currently untested (and it never was tested)

[nodejs-github-bot]

Review requested:

• @nodejs/loaders
• @nodejs/typescript

[GeoffreyBooth]

Looking good! I like this approach, it feels like a good way to unflag strip-types and provide convenience to the vast majority of users, while providing an option to be explicit for edge cases.

@joyeecheung should review the additions to lib/internal/process/execution.js, I feel like I’ve worked in that file in the past and she’s had notes for me.

[codecov]

Codecov Report

Attention: Patch coverage is 96.92737% with 11 lines in your changes missing coverage. Please review.

Project coverage is 88.46%. Comparing base (a85ef6a) to head (38d78e4).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/internal/process/execution.js	97.18%	8 Missing ⚠️
src/node_options.cc	40.00%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #56285      +/-   ##
==========================================
- Coverage   88.53%   88.46%   -0.08%     
==========================================
  Files         657      655       -2     
  Lines      190295   190165     -130     
  Branches    36538    36444      -94     
==========================================
- Hits       168482   168231     -251     
- Misses      14985    15157     +172     
+ Partials     6828     6777      -51     

Files with missing lines	Coverage Δ
lib/internal/main/eval_string.js	84.61% <100.00%> (+4.95%)	⬆️
lib/internal/modules/cjs/loader.js	98.11% <ø> (-0.01%)	⬇️
lib/internal/modules/esm/loader.js	97.87% <100.00%> (+0.06%)	⬆️
lib/internal/modules/esm/translators.js	92.88% <ø> (-0.05%)	⬇️
lib/internal/modules/typescript.js	100.00% <100.00%> (ø)
src/node_options.cc	87.87% <40.00%> (-0.11%)	⬇️
lib/internal/process/execution.js	97.81% <97.18%> (-0.98%)	⬇️

... and 36 files with indirect coverage changes

[marco-ippolito]

Starting CI because I have the feeling tests will fail on windows

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/64103/

[robpalme]

Ordered parsing, where we only attempt parse-as-TS if parse-as-JS fails, will mean that there's an edge case for ambiguous content.

globalFoo<Number>(1)

This will parse in JS as a relational expression so will never reach the TS parser.

This is just FYI. I think it is the correct behavior to prioritize the JS interpretation. The user can always explicitly override with a flag if they truly want TS.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/64123/

[marco-ippolito]

I also tried locally to unflag --experimental-strip-types.

The only --eval related failures are:

/test/message/eval_messages.js
/test/message/stdin_messages.js

Those are snapshots tests but I have no idea on how regenerate them, from what I can tell the difference is in the error stacktrace.
@nodejs/repl may have more infos

[GeoffreyBooth]

Those are snapshots tests but I have no idea on how regenerate them, from what I can tell the difference is in the error stacktrace.

See #47707