Resolution Algorithm Specification fixing

[access-control-rtfm]

Affected URL(s)

https://nodejs.org/dist/latest-v20.x/docs/api/esm.html#resolution-algorithm-specification

Description of the problem

PACKAGE_RESOLVE function step 11.1 should contains:
Let packageURL be the URL resolution of "node_modules/" concatenated with packageName, relative to parentURL.

The original PACKAGE_EXPORTS_RESOLVE is wrong if subpath is "./xyz" and the keys of exports are not starting with "." (conditions) the step 4 is executed. The suggestion how PACKAGE_EXPORTS_RESOLVE should be implemented.

PACKAGE_EXPORTS_RESOLVE(packageURL, subpath, exports, conditions)

1. If exports is an Object with both a key starting with "." and a key not starting with ".", throw an Invalid Package Configuration error.
2. Let mainExport be undefined.
3. Let resolved be undefined.
4. If subpath is equal to "." and exports is an Object containing a key equal to ".", then
   1. Let mainExport be exports["."].
5. Otherwise if exports is a String or Array, or an Object containing no keys starting with ".", then
   1. Let mainExport be exports.
6. If mainExport is not undefined, then
   1. Let resolved be the result of PACKAGE_TARGET_RESOLVE(packageURL, mainExport, null, false, conditions).
7. Otherwise, if exports is an Object and all keys of exports start with ".", then
   1. Let resolved be the result of PACKAGE_IMPORTS_EXPORTS_RESOLVE(subpath, exports, packageURL, false, conditions).
8. If resolved is not null or undefined, then return resolved.
9. Throw a Package Path Not Exported error.

[aduh95]

Do you want to open a PR instead? A code diff would be easier to follow than a written description of the proposed changes.

[access-control-rtfm]

Do you want to open a PR instead? A code diff would be easier to follow than a written description of the proposed changes.

I don't discuss a code review, but the algorithm description, which is published under the link above. I used a similar language description which is used there.

[zodern]

I'm working on updating a resolver implementation to support the package.json exports field, and noticed this too. The current line is Let packageURL be the URL resolution of "node_modules/" concatenated with packageSpecifier, relative to parentURL.

This seems to fail when the packageSpecifier is something like svelte/store, where store does not exist on disk and is only in the package.json exports. Since it doesn't exist, step 11.3 will have it keep looking at parent folders. The current wording seems to be how it worked before there were package.json exports, and it should now use the packageName instead of packageSpecifier. The current steps 11.5 and 11.7 handle resolving the rest of the package specifier (the packageSubpath).