fix(vite): resolve nested node_modules requests for install-linked dependencies - #11559

PR Checklist

• The PR title follows our guidelines.
• There is an issue for the bug/feature this PR is for.
• You have signed the CLA.
• All existing tests are passing.
• Tests for the changes are included.

What is the current behavior?

Some apps install a dependency as a symlink to a source checkout outside the app. This happens with link:, portal:, or file:<dir>, or when a pnpm readPackage hook links a checkout while package.json keeps a version like "auth": "1.0.0".

If that checkout has its own node_modules (for example, a native plugin that only auth depends on), the device can't load from it:

GET /ns/m/node_modules/@scope/sign-in/index  → 404

Three things cause this, and each one alone is enough to produce the 404:

1. resolveCandidateFilePath only looks under the project root and the monorepo workspace root. It never looks where the linked dependency actually lives.
2. filterExistingNodeModulesTransformCandidates can find the file somewhere else but still return the original /node_modules/... URL, which points at a file that doesn't exist. This happens when there is no separate workspace root, or when the file is inside the project. For example, with auth: link:./framework/packages/auth, the file is found at framework/packages/auth/node_modules/@scope/sign-in/common.js, but Vite is asked for node_modules/@scope/sign-in/common.js.
3. server.fs.allow only adds the monorepo root. Vite refuses /@fs/ paths inside an external checkout even when the URL is right.

What is the new behavior?

• New getLinkedDependencyRoots(projectRoot) in helpers/project.ts lists the directories of declared dependencies that are source checkouts:

  • link:, portal: and file:<dir> targets;
  • node_modules/<name> symlinks whose real path is outside any node_modules. This excludes registry installs and package stores.

  The result is cached per project root.

• resolveCandidateFilePath keeps its current lookup order. When the project and workspace lookups miss, it also checks each linked checkout's node_modules, then the packages of that checkout's workspace. It reuses the existing listWorkspaceNodeModulesDirs scan.

• filterExistingNodeModulesTransformCandidates returns a candidate unchanged only when it points at the file that was found. Otherwise it returns /@fs<found path>.

• resolveFsAnchoredSpec returns the path it found instead of the path it guessed.

• configuration/base.ts gets server.fs.allow from a new getDevServerFsAllow(projectRoot). It adds each linked checkout's workspace root (or the checkout itself if it has none). When nothing needs adding it returns [], so the config is unchanged for apps without linked checkouts.

Reproduction

The app depends on "auth": "1.0.0". app/node_modules/auth is a symlink to checkout/packages/auth, and that package has @scope/sign-in in its own node_modules. The test runs a real Vite 8.3.4 server and serves /ns/m through createNsMRequestContext and resolveNsMTransformedModule.

Tests

The new specs are in helpers/project.spec.ts, websocket-module-specifiers.spec.ts and websocket-ns-m-request.spec.ts. The resolution and anchoring cases fail on main.

npx vitest run in packages/vite: 1853 passed, 1 skipped.

Notes

• If several linked checkouts contain the same package, the first match wins. The URL doesn't say which package imported it. The existing workspace scan has the same limitation.
• If an app has linked checkouts but no monorepo root, fs.allow becomes [projectRoot, ...linkedRoots] instead of Vite's default searchForWorkspaceRoot(projectRoot). These differ only when Vite detects a workspace marker that findMonorepoWorkspaceRoot ignores, such as a pnpm-workspace.yaml that only holds settings. The existing monorepo branch already behaves this way.
• Not tested on a device.