-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
Refine package name validations in esm resolver #28965
Conversation
@@ -0,0 +1,18 @@ | |||
// Flags: --experimental-modules |
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.
Since this gets missed now, it may be good to add a test for exports that ensures that they aren't applied for exactly the case of ../hidden.js
even if the parent directory happens to have a package.json
file that doesn't export hidden.js
.
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'm not sure I follow this point or how it relates to this PR, can you clarify which test file changes you are referring to?
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.
Not necessary as part of this PR. More a "oops, guess we never had a regression test covering this".
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 still don't understand the exact regression / issue?
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.
We started treating ../
as a package name and would've loaded the export map etc. (I assume) but none of our tests broke. At least that's my current understanding. In other words: We don't have the following test right now:
// test/fixtures/node_modules/pkg-exports/lib/a.mjs
import '../hidden.js'; // should succeed but would be broken if ../package.json exports is applied
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.
Oh I see. But we don't get this far here because plain specifier detection doesn't catch ./
, ../
, /
or URLs.
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.
Ah, may have lost track of that. Added a quick note to the exports project board just in case. This PR may not have broken it but I'd feel better if we had a test to ensure it in the future as well. :)
38fe5cc
to
acfad9d
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.
Landed in 0e03c44 |
PR-URL: nodejs#28965 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Jan Krems <jan.krems@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
PR-URL: #28965 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Jan Krems <jan.krems@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
This ensures that the way package name parsing is done in the ESM resolver is consistent and well-defined based on the rules:
This also gives us consistency when dealing with package names between the CJS and ESM exports handling.
Effectively we can then think of
import 'x/y'
as having the package name only being allowed to exist as a valid package name, while the./y
component can in theory exist in URL space with percent encodings support.If package names want to contain non-standard characters then they must be valid file paths, and not URL percent-encoded.
npm already restricts package names effectively to
/^(@[-a-zA-Z\d][-_\.a-zA-Z\d]*\/)?[-a-zA-Z\d][-_\.a-zA-Z\d]*/$
, so that this is still a pretty unrestricted validation, the main thing is to avoid odd edge cases with things like percent-encoded backtracking.An alternative here could just be to disallow the percent encodings of
/
and\\
explicitly, instead of all percent encodings, which I'd be open to as well.Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes