Refine package name validations in esm resolver #28965
Conversation
nodejs-github-bot
added
the
c++
addaleax
added
the
esm
| @@ -0,0 +1,18 @@ | |||
| // Flags: --experimental-modules | |||
There was a problem hiding this comment.
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.
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.
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.
I still don't understand the exact regression / issue?
There was a problem hiding this comment.
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 appliedThere was a problem hiding this comment.
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.
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. :)
guybedford
force-pushed
the
pkgname
branch
2 times, most recently
from
38fe5cc
to
acfad9d
Compare
jkrems
added
the
author ready
|
Landed in 0e03c44 |
PR-URL: nodejs#28965 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Jan Krems <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: #28965 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Jan Krems <[email protected]> Reviewed-By: Rich Trott <[email protected]>
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./ycomponent 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