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.54%. Comparing base (a9e65f6) to head (ec519b5).
Report is 289 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.54%   +0.01%     
==========================================
  Files         657      657              
  Lines      190395   190700     +305     
  Branches    36555    36590      +35     
==========================================
+ Hits       168567   168864     +297     
- Misses      15002    15014      +12     
+ Partials     6826     6822       -4     

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	91.45% <ø> (-0.05%)	⬇️
lib/internal/modules/typescript.js	100.00% <100.00%> (ø)
src/node_options.cc	87.92% <40.00%> (-0.10%)	⬇️
lib/internal/process/execution.js	97.81% <97.18%> (-0.98%)	⬇️

... and 26 files with indirect coverage changes

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[pmarchini]

LGTM

[GeoffreyBooth]

What I found with syntax detection is that if you rethrow an exception in JavaScript, the first line (the source of the error) changes to Node internals rather than being the actual line of code the error originated from. The only way to prevent this was to do everything in C++. There might not be a test for this specifically for eval input; there should be, and there was for file input. I went down the same road of implementing the whole thing in JavaScript and stumbling onto this and then needing to redo it in C++ with the help of @targos and @joyeecheung.

[marco-ippolito]

I mean it's eval does it really matter that we adding a line in the stacktrace? We don't have this problem for files.

[marco-ippolito]

There is no difference:

marcoippolito@marcos-MacBook-Pro node % node -e "throw new Error('yo')"                                                
[eval]:1
throw new Error('yo')
^

Error: yo
    at [eval]:1:7
    at runScriptInThisContext (node:internal/vm:209:10)
    at node:internal/process/execution:118:14
    at [eval]-wrapper:6:24
    at runScript (node:internal/process/execution:101:62)
    at evalScript (node:internal/process/execution:136:3)
    at node:internal/main/eval_string:55:3

Node.js v22.10.0
marcoippolito@marcos-MacBook-Pro node % ./node --experimental-strip-types -e "throw new Error('yo')"
[eval]:1
throw new Error('yo')
^

Error: yo
    at [eval]:1:7
    at runScriptInThisContext (node:internal/vm:209:10)
    at node:internal/process/execution:478:12
    at [eval]-wrapper:6:24
    at runScriptInContext (node:internal/process/execution:476:60)
    at evalTypeScript (node:internal/process/execution:316:3)
    at node:internal/main/eval_string:71:3

Node.js v24.0.0-pre

[nodejs-github-bot]

Landed in da3f388