-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
module: support eval with ts syntax detection #56285
module: support eval with ts syntax detection #56285
Conversation
Review requested:
|
7229405
to
f0f0e3c
Compare
f0f0e3c
to
728a1fd
Compare
3485014
to
1dd1cb5
Compare
2f87a9c
to
aeb77e9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 ReportAttention: Patch coverage is
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
|
78e6970
to
38d78e4
Compare
I also tried locally to unflag The only --eval related failures are:
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 |
38d78e4
to
ec519b5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
} catch (tsError) { | ||
// If its not an error, or it's not an invalid typescript syntax error, rethrow it. | ||
if (!isError(tsError) || tsError?.code !== 'ERR_INVALID_TYPESCRIPT_SYNTAX') { | ||
throw tsError; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
Landed in da3f388 |
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:
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 throwERR_INVALID_TYPESCRIPT_SYNTAX
safely