fix: prefer exports when resolving

[benmccann]

Description

Closes #10352

Additional context

Svelte has a package.json in each directory to support older versions of Node since exports is only present in Node 12 and newer. Vite is preferring these nested package.json files over the exports field which is incorrect

The code was also assuming all modules are required, which is wrong since it uses a dynamic import for everything

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[bluwy]

Thanks for fixing this!

[aleclarson]

I don't think this is actually the root package ID, unless you mean something different than "the @foo/bar part of @foo/bar/x/y/z".

Reason being, the possiblePkgIds array is reversed in the statement before this one.

[benmccann]

Ah, you're probably right about that

[aleclarson]

I created a test project since I was having a hard time interpreting the spec. What I found is that it will only use exports from the package.json in the package root, but it will use the package.json in subdirectories to determine whether to interpret the file as ESM or CJS, which sounds like what you said.
– Ben McCann (#10371 (comment))

It seems dangerous to infer Node's intended behavior from its implementation instead of its specification, as the observed behavior could be unintended and fixed in Node later on without us the wiser.

[aleclarson]

Svelte has a package.json in each directory to support older versions of Node since exports is only present in Node 12 and newer. Vite is preferring these nested package.json files over the exports field which is incorrect

What issue does this cause? Can't you just keep the main/module fields in each nested package.json aligned with the exports field from the top-level package.json?

[aleclarson]

@benmccann Does Node.js only check the "root package" for an exports field, or does it search in each parent directory of the import ID and stop at the first exports field it finds?

[benmccann]

It seems dangerous to infer Node's intended behavior from its implementation instead of its specification, as the observed behavior could be unintended and fixed in Node later on without us the wiser.

I don't think Node could change its behavior and randomly break working packages.

What issue does this cause?

Vite was resolving to the wrong file

Can't you just keep the main/module fields in each nested package.json aligned with the exports field from the top-level package.json?

They are

Does Node.js only check the "root package" for an exports field, or does it search in each parent directory of the import ID and stop at the first exports field it finds?

If I recall correctly, I believe it only checks the root package

[aleclarson]

What issue does this cause?

Vite was resolving to the wrong file

Can't you just keep the main/module fields in each nested package.json aligned with the exports field from the top-level package.json?

They are

These two answers seem to conflict, or am I missing something? How was Vite resolving to the wrong file if both the root and nested package.json point to the same file?

[benmccann]

I can't recall anymore. I'd have to go back to an old version of Vite and run it against Svelte again. That being said, I'm not sure the answer would change much. This is part of the Node resolution algorithm and is something we should probably support regardless.

[benmccann]

I went back and looked at the original bug report and it refreshed my memory.

The root package.json looks like:

    "./internal": {
      "types": "./types/runtime/internal/index.d.ts",
      "import": "./internal/index.mjs",
      "require": "./internal/index.js"
    },

And then the sub-directory or sub-package or whatever you want to call it looks like:

{
  "main": "./index",
  "module": "./index.mjs",
  "types": "./index.d.ts"
}

I believe the issue here is that the module field is only used when the package is in ssr.noExternal. I'm thinking now that we probably could add an exports map to the Svelte sub-package as a workaround. But that's really just a workaround and it's better to fix Vite.

[bluwy]

Yup, to add on Ben's explanation, Node.js treats exports differently, that if the exports is define in the root package.json, it should respect that instead of any subdirectories' package.json. Previously Vite was checking closest package.json regardless which deviates from Node.js resolution algorithm. https://nodejs.org/api/esm.html#resolver-algorithm-specification (PACKAGE_RESOLVE no11 > no5, where packageSpecifier doesn't include the import subpath)

[aleclarson]

Node.js treats exports differently, that if the exports is define in the root package.json, it should respect that instead of any subdirectories' package.json.

Ah yes, that looks to be correct, now that I look at the spec.

PACKAGE_RESOLVE
…
9. Let selfUrl be the result of PACKAGE_SELF_RESOLVE(packageName, packageSubpath, parentURL).

That PACKAGE_SELF_RESOLVE call runs before the parent directories are searched, so the root exports will take precedence as Ben stated. 👍