nextjs - ✅(Solved) Fix Turbopack fails to resolve next/package.json with pnpm v11 enableGlobalVirtualStore [1 pull requests, 1 participants]

yamaaaaaa31 · 2026-05-07T01:03:19Z

[nextjs] PR 92886: Support cross-root symlinks in Turbopack's filesystem layer, fixing module resolution failures in Bazel-sandboxed builds. - Repository: verc… # PR #92886: Support cross-root symlinks in Turbopack's filesystem layer, fixing module resolution failures in Bazel-sandboxed builds. - Repository: vercel/next.js - Author: gustav-joelsson - State: open | merged: False - Link: https://github.com/vercel/next.js/pull/92886 ## Description (problem / solution / changelog) ### What? Support cross-root symlinks in Turbopack's filesystem layer, fixing module resolution failures in Bazel-sandboxed builds. ### Why? Fixes https://github.com/vercel/next.js/issues/91896 In Bazel builds, `rules_js` assembles `node_modules` via symlink chains that ultimately point outside the Turbopack filesystem root. When `read_link()` encounters such a symlink, it returns `LinkContent::Invalid` and the entry is silently dropped — causing `next build --turbopack` to fail to resolve packages. ### How? - Added `classify_cross_root_symlink()` — a centralized helper that falls back to OS-level metadata (via `retry_blocking`) when a symlink target is outside the fs root, classifying it as File/Directory/Other - Updated `get_type()`, `realpath_with_links()`, `read_matches()` (both fast and slow paths), and `read_glob()` to handle `LinkContent::Invalid` using this helper - Added `resolve_symlink()` calls in `pages_structure.rs`, `app_structure.rs`, `require_context.rs`, and `import_meta_glob.rs` so symlinked entries aren't silently dropped during directory iteration - Added `cross_root: bool` to `RealPathResult` so callers can distinguish cross-root paths from true canonical paths ### Tests added - `test_cross_root_symlink` — relative symlink escaping the fs root, validates `get_type` and `realpath_with_links` - `test_cross_root_symlink_absolute` — absolute symlink (actual Bazel scenario), verifies the `cross_root` flag - `test_subdir_symlinks_need_resolve_for_match` — demonstrates `resolve_symlink()` is required for cross-root directory entries - `test_pages_structure_finds_symlinked_pages_in_subdirs` — end-to-end pages router discovery with cross-root symlinks - `test_resolve_across_bazel_sandbox_symlinks` — multi-hop symlink chain mimicking `rules_js` layout Fixes #91896 ## Changed files - `Cargo.lock` (modified, +3/-0) - `crates/next-core/Cargo.toml` (modified, +5/-0) - `crates/next-core/src/app_structure.rs` (modified, +2/-2) - `crates/next-core/src/pages_structure.rs` (modified, +91/-0) - `turbopack/crates/turbo-tasks-fs/src/lib.rs` (modified, +346/-1) - `turbopack/crates/turbo-tasks-fs/src/read_glob.rs` (modified, +26/-11) - `turbopack/crates/turbopack-core/src/resolve/mod.rs` (modified, +88/-0) - `turbopack/crates/turbopack-core/src/resolve/pattern.rs` (modified, +106/-33) - `turbopack/crates/turbopack-ecmascript/src/references/import_meta_glob.rs` (modified, +1/-1) - `turbopack/crates/turbopack-ecmascript/src/references/require_context.rs` (modified, +2/-1) ## Fix / Workaround Expected behavior: Turbopack should handle pnpm v11 global virtual store symlinks for normal runtime dependencies, including Next.js itself, or provide a clear error/workaround. In this setup, `realpath(node_modules/next/package.json)` points outside the project root. Setting `turbopack.root` to the app root is not enough. A workaround is to set `turbopack.root` to the common ancestor of the app root and the real path of `node_modules/next/package.json`, but that can become a very broad directory such as the user's home directory. Workarounds observed: ### Link to the code that reproduces this issue https://github.com/yamaaaaaa31/turbopack-pnpm-v11-repro ### To Reproduce 1. Clone the reproduction repository. 2. Use pnpm v11. 3. Make sure pnpm global virtual store is enabled: ```yaml # pnpm-workspace.yaml enableGlobalVirtualStore: true ``` 4. Install dependencies: ```bash pnpm install ``` 5. Start the development server with Turbopack: ```bash pnpm dev ``` 6. Open the app route in the browser. ### Current vs. Expected behavior When `enableGlobalVirtualStore: true` is enabled in pnpm v11, `node_modules/next` is a symlink whose real path points outside the project root, for example: ```text node_modules/next -> ~/Library/pnpm/store/v11/links/.../node_modules/next ``` With Turbopack, `next dev` fails when serving the app because it cannot resolve `next/package.json`: ```text Couldn't find the Next.js package (next/package.json) from project directory: /src/app ``` Expected behavior: Turbopack should handle pnpm v11 global virtual store symlinks for normal runtime dependencies, including Next.js itself, or provide a clear error/workaround. This does not happen when using webpack dev mode. Additional verification: - This also reproduces with `next@canary`. - This is not specific to `output: "standalone"`. The linked reproduction does not set `output: "standalone"` and still reproduces. - Setting `experimental.externalDir: true` does not address this

nextjs2026-05-07 01:03:19

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

vercel/next.js#93556•Fetched 2026-05-07 03:30:22

View on GitHub

Comments

Participants

Timeline

Reactions

Author

yamaaaaaa31

Participants

yamaaaaaa31

Timeline (top)

issue_type_added ×1labeled ×1

Error Message

Expected behavior: Turbopack should handle pnpm v11 global virtual store symlinks for normal runtime dependencies, including Next.js itself, or provide a clear error/workaround.

Root Cause

With Turbopack, next dev fails when serving the app because it cannot resolve next/package.json:

Fix Action

Fix / Workaround

Expected behavior: Turbopack should handle pnpm v11 global virtual store symlinks for normal runtime dependencies, including Next.js itself, or provide a clear error/workaround.

In this setup, realpath(node_modules/next/package.json) points outside the project root. Setting turbopack.root to the app root is not enough. A workaround is to set turbopack.root to the common ancestor of the app root and the real path of node_modules/next/package.json, but that can become a very broad directory such as the user's home directory.

Workarounds observed:

PR fix notes

PR #92886: Support cross-root symlinks in Turbopack's filesystem layer, fixing module resolution failures in Bazel-sandboxed builds.

Repository: vercel/next.js
Author: gustav-joelsson
State: open | merged: False
Link: https://github.com/vercel/next.js/pull/92886

Description (problem / solution / changelog)

What?

Support cross-root symlinks in Turbopack's filesystem layer, fixing module resolution failures in Bazel-sandboxed builds.

Why?

Fixes https://github.com/vercel/next.js/issues/91896

In Bazel builds, rules_js assembles node_modules via symlink chains that ultimately point outside the Turbopack filesystem root. When read_link() encounters such a symlink, it returns LinkContent::Invalid and the entry is silently dropped — causing next build --turbopack to fail to resolve packages.

How?

Added classify_cross_root_symlink() — a centralized helper that falls back to OS-level metadata (via retry_blocking) when a symlink target is outside the fs root, classifying it as File/Directory/Other
Updated get_type(), realpath_with_links(), read_matches() (both fast and slow paths), and read_glob() to handle LinkContent::Invalid using this helper
Added resolve_symlink() calls in pages_structure.rs, app_structure.rs, require_context.rs, and import_meta_glob.rs so symlinked entries aren't silently dropped during directory iteration
Added cross_root: bool to RealPathResult so callers can distinguish cross-root paths from true canonical paths

Tests added

test_cross_root_symlink — relative symlink escaping the fs root, validates get_type and realpath_with_links
test_cross_root_symlink_absolute — absolute symlink (actual Bazel scenario), verifies the cross_root flag
test_subdir_symlinks_need_resolve_for_match — demonstrates resolve_symlink() is required for cross-root directory entries
test_pages_structure_finds_symlinked_pages_in_subdirs — end-to-end pages router discovery with cross-root symlinks
test_resolve_across_bazel_sandbox_symlinks — multi-hop symlink chain mimicking rules_js layout

Fixes #91896

Changed files

Cargo.lock (modified, +3/-0)
crates/next-core/Cargo.toml (modified, +5/-0)
crates/next-core/src/app_structure.rs (modified, +2/-2)
crates/next-core/src/pages_structure.rs (modified, +91/-0)
turbopack/crates/turbo-tasks-fs/src/lib.rs (modified, +346/-1)
turbopack/crates/turbo-tasks-fs/src/read_glob.rs (modified, +26/-11)
turbopack/crates/turbopack-core/src/resolve/mod.rs (modified, +88/-0)
turbopack/crates/turbopack-core/src/resolve/pattern.rs (modified, +106/-33)
turbopack/crates/turbopack-ecmascript/src/references/import_meta_glob.rs (modified, +1/-1)
turbopack/crates/turbopack-ecmascript/src/references/require_context.rs (modified, +2/-1)

Code Example

# pnpm-workspace.yaml
enableGlobalVirtualStore: true

---

pnpm install

---

pnpm dev

---

node_modules/next -> ~/Library/pnpm/store/v11/links/.../node_modules/next

---

Couldn't find the Next.js package (next/package.json)
from project directory: <project>/src/app

---

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.4.0
  Available memory (MB): 49152
  Available CPU cores: 14
Binaries:
  Node: 22.22.2
  npm: 10.9.7
  Yarn: N/A
  pnpm: 11.0.6
Relevant Packages:
  next: 16.2.4
  eslint-config-next: N/A
  react: 19.2.5
  react-dom: 19.2.5
  typescript: N/A
Next.js Config:
  output: N/A

RAW_BUFFERClick to expand / collapse

Link to the code that reproduces this issue

https://github.com/yamaaaaaa31/turbopack-pnpm-v11-repro

To Reproduce

Clone the reproduction repository.
Use pnpm v11.
Make sure pnpm global virtual store is enabled:

# pnpm-workspace.yaml
enableGlobalVirtualStore: true

Install dependencies:

pnpm install

Start the development server with Turbopack:

pnpm dev

Open the app route in the browser.

Current vs. Expected behavior

When enableGlobalVirtualStore: true is enabled in pnpm v11, node_modules/next is a symlink whose real path points outside the project root, for example:

node_modules/next -> ~/Library/pnpm/store/v11/links/.../node_modules/next

With Turbopack, next dev fails when serving the app because it cannot resolve next/package.json:

Couldn't find the Next.js package (next/package.json)
from project directory: <project>/src/app

Expected behavior: Turbopack should handle pnpm v11 global virtual store symlinks for normal runtime dependencies, including Next.js itself, or provide a clear error/workaround.

This does not happen when using webpack dev mode.

Additional verification:

This also reproduces with next@canary.
This is not specific to output: "standalone". The linked reproduction does not set output: "standalone" and still reproduces.
Setting experimental.externalDir: true does not address this. The failure appears to happen at Turbopack's filesystem root / symlink resolution layer, before regular external source imports.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.4.0
  Available memory (MB): 49152
  Available CPU cores: 14
Binaries:
  Node: 22.22.2
  npm: 10.9.7
  Yarn: N/A
  pnpm: 11.0.6
Relevant Packages:
  next: 16.2.4
  eslint-config-next: N/A
  react: 19.2.5
  react-dom: 19.2.5
  typescript: N/A
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Turbopack

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

This seems related to pnpm v11's enableGlobalVirtualStore: true.

Workarounds observed:

pnpm dev --webpack works.
Disabling enableGlobalVirtualStore avoids the issue.
Setting turbopack.root to the common ancestor of the app root and realpath(node_modules/next/package.json) works, but in real projects this can require broadening the root to a directory like the user's home directory, which is not a practical default.

Related issues / PRs:

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

#LLM response #prompt template #agent execution #callback error #memory management

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Data

Security

Network

Code

UI/UX

Text

System

Multimedia

Protocol

API

Engineering

nextjs - ✅(Solved) Fix Turbopack fails to resolve next/package.json with pnpm v11 enableGlobalVirtualStore [1 pull requests, 1 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Fix Action

Fix / Workaround

PR fix notes

PR #92886: Support cross-root symlinks in Turbopack's filesystem layer, fixing module resolution failures in Bazel-sandboxed builds.

Description (problem / solution / changelog)

What?

Why?

How?

Tests added

Changed files

Code Example

Link to the code that reproduces this issue

To Reproduce

Current vs. Expected behavior

Provide environment information

Which area(s) are affected? (Select all that apply)

Which stage(s) are affected? (Select all that apply)

Additional context

Still need to ship something?

TRENDING

nextjs - ✅(Solved) Fix Turbopack fails to resolve next/package.json with pnpm v11 enableGlobalVirtualStore [1 pull requests, 1 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Fix Action

Fix / Workaround

PR fix notes

PR #92886: Support cross-root symlinks in Turbopack's filesystem layer, fixing module resolution failures in Bazel-sandboxed builds.

Description (problem / solution / changelog)

What?

Why?

How?

Tests added

Changed files

Code Example

Link to the code that reproduces this issue

To Reproduce

Current vs. Expected behavior

Provide environment information

Which area(s) are affected? (Select all that apply)

Which stage(s) are affected? (Select all that apply)

Additional context

Still need to ship something?

RELATED_DISCOVERY

TRENDING