-
Notifications
You must be signed in to change notification settings - Fork 30.4k
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: fix regression in main ESM loading #15736
Conversation
cce78f8
to
80b98a5
Compare
continue; | ||
} | ||
throw new Error('Executing node with inexistent entry point should ' + | ||
`fail. Entry point: ${entryPoint}, Flags: [${args}]`); |
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.
assert.fail()
here instead of the throw?
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 with a comment/suggestion.
for (const args of flags) { | ||
for (const entryPoint of entryPoints) { | ||
try { | ||
await execFile(node, args.concat(entryPoint)); |
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.
Could the test be simplified by using execFileSync()
instead?
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.
But isn't using async-await cooler 😁 ?
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.
Haha I totally forgot there was a sync version! I was only thinking about how complicated it would be with callbacks xD.
When the requested module cannot be resolved to a file, loading should always fail, regardless of wether ESM is enabled or not. Fixes: nodejs#15732
bfa4db3
to
1d9d6ed
Compare
There is something weird. I changed the test to use |
I think #13601 might have gone too far and removed properties that are supposed to be there according to the docs. |
/cc @mscdex |
Confirmed that 448c4c6 is the commit that introduces the change, using script provided by @targos: t.jsconst { execFileSync } = require('child_process');
try {
execFileSync(process.argv[0], ['xxx'], {stdio: 'ignore'});
} catch (e) {
console.log(Object.keys(e));
} Commit before 448c4c6$ ./node t.js
[ 'error',
'file',
'args',
'options',
'envPairs',
'stderr',
'stdout',
'pid',
'output',
'signal',
'status' ] Commit 448c4c6$ ./node t.js
[ 'status', 'signal' ] |
Quick fix: diff --git a/lib/child_process.js b/lib/child_process.js
index a3cdadd..f041a86 100644
--- a/lib/child_process.js
+++ b/lib/child_process.js
@@ -566,8 +566,8 @@ function checkExecSyncError(ret, args, cmd) {
err = new Error(msg);
}
if (err) {
- err.status = ret.status < 0 ? errname(ret.status) : ret.status;
- err.signal = ret.signal;
+ Object.assign(err, ret);
}
return err;
} |
I will see when I'm back from vacation (Oct 23) |
This simplifies the top-level load when ES modules are enabled as we can entirely delegate the module resolver, which will hand over to CommonJS where appropriate. All not found errors are made consistent to throw during resolve and have the MODULE_NOT_FOUND code. Includes the test case from nodejs#15736
I'm going to close this one because #16147 takes care of it. |
This simplifies the top-level load when ES modules are enabled as we can entirely delegate the module resolver, which will hand over to CommonJS where appropriate. All not found errors are made consistent to throw during resolve and have the MODULE_NOT_FOUND code. Includes the test case from #15736. Fixes: #15732 PR-URL: #16147 Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
This simplifies the top-level load when ES modules are enabled as we can entirely delegate the module resolver, which will hand over to CommonJS where appropriate. All not found errors are made consistent to throw during resolve and have the MODULE_NOT_FOUND code. Includes the test case from #15736. Fixes: #15732 PR-URL: #16147 Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
This simplifies the top-level load when ES modules are enabled as we can entirely delegate the module resolver, which will hand over to CommonJS where appropriate. All not found errors are made consistent to throw during resolve and have the MODULE_NOT_FOUND code. Includes the test case from nodejs/node#15736. Fixes: nodejs/node#15732 PR-URL: nodejs/node#16147 Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
This simplifies the top-level load when ES modules are enabled as we can entirely delegate the module resolver, which will hand over to CommonJS where appropriate. All not found errors are made consistent to throw during resolve and have the MODULE_NOT_FOUND code. Includes the test case from nodejs/node#15736. Fixes: nodejs/node#15732 PR-URL: nodejs/node#16147 Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>
When the requested module cannot be resolved to a file, loading should
always fail, regardless of wether ESM is enabled or not.
Fixes: #15732
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes