Review requested:

• @nodejs/loaders
• @nodejs/typescript

I wonder why do we have to emit the warning - can't we just strip it always for --eval and compare the stripped code with the original and see if it's modified before emitting the warning? Maybe minus the platform where swc crashes...or use something that doesn't crash for it.

Also, alternatively we can just skip the entrypoint warning for --eval, since the warning is temporary and will hopefully go away eventually, it seems simplicity of not introducing another flag that will stay after the temporary warning runs its course outweighs whatever the warning serves.

Even if we dont emit a warning the syntax errors are wrapped by swc.
For example function foo(){ await Promise.resolve(1)} when strip types is enabled it will throw an "INVALID_TYPESCRIPT_SYNTAX_ERROR" rather than the usual syntax error.
Also the crash is only for loaders so in eval should be fine (? I guess)

For example function foo(){ await Promise.resolve(1)} when strip types is enabled it will throw an "INVALID_TYPESCRIPT_SYNTAX_ERROR" rather than the usual syntax error.

Is that thrown during type stripping? If the error is identifyable I think we can just catch it in that case, and move on to parse/evaluate the original source?

For example function foo(){ await Promise.resolve(1)} when strip types is enabled it will throw an "INVALID_TYPESCRIPT_SYNTAX_ERROR" rather than the usual syntax error.

Is that thrown during type stripping? If the error is identifyable I think we can just catch it in that case, and move on to parse/evaluate the original source?

Yes the error is thrown during type stripping.
There is no way to distinguish between a invalid typescript syntax error (example you are using enums in type stripping) vs a generic syntax error. @kdy1 maybe knows more

Or a solution could be to wrap all INVALID_TYPESCRIPT_SYNTAX_ERROR when using eval in a normal syntax error 🤷🏼
The error message will change but at least should throw the same error and remove the warning.
Doing so will change the error message:

marcoippolito@marcos-MBP node % ./node --experimental-strip-types -e "function foo(){ await Promise.resolve(1) }"
node:internal/main/eval_string:41
      throw new SyntaxError(error.message);
      ^

SyntaxError:   x await isn't allowed in non-async function
   ,----
 1 | function foo(){ await Promise.resolve(1) }
   :                       ^^^^^^^
   `----


Caused by:
    failed to parse
    at node:internal/main/eval_string:41:13

Node.js v24.0.0-pre
marcoippolito@marcos-MBP node % ./node -e "function foo(){ await Promise.resolve(1) }" 
[eval]:1
function foo(){ await Promise.resolve(1) }
                ^^^^^

SyntaxError: await is only valid in async functions and the top level bodies of modules
    at makeContextifyScript (node:internal/vm:185:14)
    at node:internal/process/execution:107:22
    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:69:3

Node.js v24.0.0-pre

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.54%. Comparing base (a50f3d5) to head (c5704d8).
Report is 6 commits behind head on main.

@@            Coverage Diff             @@
##             main   #56273      +/-   ##
==========================================
- Coverage   88.55%   88.54%   -0.01%     
==========================================
  Files         657      657              
  Lines      190243   190243              
  Branches    36536    36541       +5     
==========================================
- Hits       168461   168450      -11     
- Misses      14963    14968       +5     
- Partials     6819     6825       +6     

... and 24 files with indirect coverage changes

Found a workaround 😄 I'll open a new PR