-
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
esm: add experimental support for addon modules #55844
base: main
Are you sure you want to change the base?
Conversation
Review requested:
|
d4b9a9a
to
b384e80
Compare
c6ce9fd
to
0c724cd
Compare
The commit message does not meet our guidelines, the word after the subsystem should be an infinitive verb. I suggest |
9841645
to
829cfc6
Compare
829cfc6
to
2ea455d
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #55844 +/- ##
==========================================
- Coverage 88.55% 88.54% -0.01%
==========================================
Files 657 657
Lines 190243 190372 +129
Branches 36536 36546 +10
==========================================
+ Hits 168461 168571 +110
- Misses 14963 14991 +28
+ Partials 6819 6810 -9
|
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.
Thanks for this 🙂
for the tests, describe etc provide significantly better DX when tests fail
|
||
export async function run() { | ||
// binding.node | ||
{ |
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.
Please use describe
+ it
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 personally find describe
+ it
to be worse UX due to the reasons stated in #56027 (comment), unless there is a way to silence the passing tests and make the console logs from the failed test cases appear at the end together with the errors..
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.
Some suggestions, but non-blocking.
Addon export names can not be inferred until it is evaluated.
I wonder if there's anything we can do about it...potentially, defining some macro in node.h that the addons can use to export names with a specific pattern, which we can scan for by parsing the dynamic library (ideally through some new API in libuv, though we are already parsing binaries using postject for SEA which implements the parsing by itself...). Can be done as a follow-up, of course..
@@ -23,6 +24,10 @@ if (experimentalWasmModules) { | |||
extensionFormatMap['.wasm'] = 'wasm'; | |||
} | |||
|
|||
if (experimentalAddonModules) { | |||
extensionFormatMap['.node'] = 'addon'; |
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 am somewhat surprised to find that there is not a test for the node-addons
exports condition...it seems the the files pointed to by node-addons
won't get interpreted as addons unless they have the .node
extension, though this issue predates this PR and also happens to require()
.
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.
Taking a step back, I'm wondering if the format name could be renamed as node-addon
/node-addons
for alignment.
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.
Sure, also I am not even sure if anyone is actually using it, it seems only useful to distinguish "if the current run times can load Node.js style addons" as it currently stands, so may not really be that big of a deal anyway....
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 prefer the more concise addon
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.
Actually I think I misread #55844 (comment) - I think for the format name, addon
or node-addon
would make more sense. node-addons
would be a bit weird in the hooks since it's plural.
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.
This loader format enum is specific for Node.js so I'll stick with the concise addon
.
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.
In any case, the exports condition question is separate - it's more about when a module that doesn't end with .node
is pointed to by node-addons
, should it be interpreted(translated) into an addon or should it be interpreted based on whatever extension it has - and if it has a different extension (e.g. dylib or dll), what should happen then. As I said in the first comment, it's fine to keep it as is since CJS also only considers .node
, but it is a bit strange for the exports condition.
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.
The reality is that the conditional exported entries are been loaded based on their extensions, not their entry types. With require(esm)
, it is possible to do the following already 👀:
{
"exports": {
"import": "./index-require.cjs",
"require": "./index-module.mjs"
}
}
|
||
export async function run() { | ||
// binding.node | ||
{ |
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 personally find describe
+ it
to be worse UX due to the reasons stated in #56027 (comment), unless there is a way to silence the passing tests and make the console logs from the failed test cases appear at the end together with the errors..
This needs a rebase. |
7375fa0
to
16777e3
Compare
This comment was marked as outdated.
This comment was marked as outdated.
16777e3
to
1992c20
Compare
Co-authored-by: Antoine du Hamel <[email protected]>
Add experimental support to loading
.node
extension modules in ESM.An addon exports two names
default
andmodule.exports
, as same asimport(cjs)
whereits export names can not be preparsed. Addon export names can not be inferred until it is evaluated.
Fixes: #40541
Fixes: #55821