Repository navigation
Ambiguous steps in PACKAGE_IMPORTS_EXPORTS_RESOLVE reference documentation #53206
Description
Activity
@nodejs/loaders
(BTW 1 & 2 return the same result)
(BTW 1 & 2 return the same result)
I figured that as well after writing it. 😅 Still, there is some ambiguity here, since it could also be interpreted as (3).
I personally don’t find it confusing (we’re talking about the key, that would make little sense to involve the value at this point), and even if you misinterpret it, it wouldn’t be too bad because the value would also typically contain a single
*. As always, PRs welcome to clarify the docs.Fair enough. But if it's the case that the key always contains a single "*", the reference of
PATTERN_KEY_COMPAREseems to have unnecessary steps. Happy to open a PR to update this.Let me rephrase that: value associated with keys that contains a single
*char will typically also contain a single*char. Keys do not always contain a single*char.Example of a valid
"exports"map:{ "exports": { "./someKey/noStar": "./someFile.mjs", "./somePatternKey/*": "./someDir/*.mjs" } }I understand that some keys don't have a "*", but the reference for
PACKAGE_IMPORTS_EXPORTS_RESOLVEmentions:Let expansionKeys be the list of keys of matchObj containing only a single "*"
So I assume an implementation for this in JS could be:
const expansionKeys = Object.keys(matchObj).filter(key => count(key, "*") === 1);
After which
expansionKeysis sorted byPATTERN_KEY_COMPARE. YetPATTERN_KEY_COMPAREincludes cases for when a key does not contain "*", which is never the case, right? It's never called for keys that don't contain a "*".Object.keys(matchObj) .filter(key => count(key, "*") === 1) .sort(PATTERN_KEY_COMPARE); // The keys here always contain a "*"
Ah I see, sorry for the misunderstanding! I think that's a relic from a time where there was another another way to define subpath patterns which was removed in #40121, and I guess
PATTERN_KEY_COMPAREwas never updated, good catch. If you want to PR a fix, that would be much appreciated.Reacted by Maarten Zuidhoorn- added a commit that references this issue
on Jun 5, 2024 - added a commit that references this issue
on Jun 7, 2024 - added a commit that references this issue
on Jun 20, 2024
Affected URL(s)
https://nodejs.org/api/esm.html#resolution-algorithm-specification
Description of the problem
I was looking at the ESM resolution algorithm documentation, and stumbled upon this:
PACKAGE_IMPORTS_EXPORTS_RESOLVE:
(2) could be interpreted in several ways, including:
Assuming (1) or (2) here is correct, the implementation of PATTERN_KEY_COMPARE seems odd:
From my understanding, neither keyA nor keyB can not contain a "*" at this point since it's filtered out. I looked at implementations of the module resolution, like Webpack's
enhanced-resolve, and it seems like previously these imports or exports could end with a/instead of containing a*:https://github.com/webpack/enhanced-resolve/blob/e38970852a7f89b694f1053e285195511764a900/lib/util/entrypoints.js#L314-L322
However, this does not seem to work in the current Node.js version (tested on v20.12.2 at least), and is not described in the reference of PACKAGE_IMPORTS_EXPORTS_RESOLVE. Are the docs outdated? Is there some ambiguity here? Or am I simply misunderstanding the docs?