-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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: package exports dot main support #29494
Conversation
//cc @nodejs/modules-active-members |
Co-Authored-By: Geoffrey Booth <GeoffreyBooth@users.noreply.github.com>
Co-Authored-By: Geoffrey Booth <GeoffreyBooth@users.noreply.github.com>
Random governance question - who is supposed to approve these changes? Modules team members or core collaborators? Has the TSC chartered the module team to make changes to this area of the code on its own or something similar? (I am asking because I see two approvals by non-collaborator members and I am a bit confused if those LGTMs are "I agree with this change and it can land" "I agree with this change" or "This is what the team said" and if regular collaborators are expected to review those or not) |
cc @MylesBorins ^ |
@benjamingr the standard Node.js core approval process applies since the modules group is not chartered. We typically seek consensus from the modules group before landing non-patch changes to the module system though. |
Thanks for explaining @guybedford! |
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 in general but I'd prefer if we can remove the duplication between the code for .
and other exports
keys.
target = | ||
exports_obj->Get(env->context(), dot_string).ToLocalChecked(); | ||
} | ||
if (target->IsString()) { |
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.
Is there a way to reuse the existing logic for string/array in PackageExportsResolve
?
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.
That would be better, it's just a refactoring I haven't had the time for. Would you be ok with moving that to a follow-up?
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.
Works for me.
It's worth noting here, that: {
"exports": "./esm-main.js"
} is supported by this PR, but: {
"exports": "esm-main.js"
} would not be supported and would throw an error that exports must start with This is based on various long-standing discussions, but still worth noting in how it deviates from |
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
🍏 |
Landed in 3f3ad38 |
This reintroduces the dot main in exports as discussed in the previous Node.js modules meeting. The implementation includes both CommonJS and ES module resolution with the associated documentation and resolver specification changes. In addition to the dot main, "exports" as a string or direct fallback array is supported as well. Co-Authored-By: Geoffrey Booth <GeoffreyBooth@users.noreply.github.com> PR-URL: #29494 Reviewed-By: Jan Krems <jan.krems@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com>
This reintroduces the dot main in exports as discussed in the previous Node.js modules meeting. The implementation includes both CommonJS and ES module resolution with the associated documentation and resolver specification changes. In addition to the dot main, "exports" as a string or direct fallback array is supported as well. Co-Authored-By: Geoffrey Booth <GeoffreyBooth@users.noreply.github.com> PR-URL: #29494 Reviewed-By: Jan Krems <jan.krems@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com>
This reintroduces the dot main in exports as discussed in the previous Node.js modules meeting. The implementation includes both CommonJS and ES module resolution with the associated documentation and resolver specification changes. In addition to the dot main, "exports" as a string or direct fallback array is supported as well. Co-Authored-By: Geoffrey Booth <GeoffreyBooth@users.noreply.github.com> PR-URL: #29494 Reviewed-By: Jan Krems <jan.krems@gmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com>
This reintroduces the dot main in exports as discussed in the previous Node.js modules meeting.
The implementation includes both CommonJS and ES module resolution with the associated documentation and resolver specification changes.
In addition to the dot main, "exports" as a string or direct fallback array is supported as well.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes