Turbopack Panics When Node_modules Symlink Points Outside Project Root In Git Worktree

Turbopack's node_modules resolution enforces a root boundary check on symlink targets. When the symlink target (e.g., the primary checkout's node_modules) lies outside the project root, Turbopack panics instead of falling back to a user-friendly error or allowing an explicit opt-in for external dependency directories.

1. Clone the reproduction repository: https://github.com/Innei/next-turbopack-external-node-modules-worktree-repro 2. Install dependencies with `pnpm install` in the primary checkout. 3. Run `./reproduce.sh` (creates a sibling Git worktree, symlinks its node_modules to the primary checkout's node_modules, and starts `next dev` from the worktree). 4. Observe the Turbopack ready message followed by the panic and exit.

This workaround only covers direct dependencies; transitive dependencies that rely on nested node_modules resolution may still trigger the panic if Turbopack encounters the symlinked directory during hoisted dependency lookups. The hardcoded path requires manual updates if the primary checkout moves or is renamed. Alias resolution may interfere with packages that use conditional exports or subpath imports, leading to incorrect module loading. Concurrent processes modifying the shared node_modules can introduce inconsistent state. On Windows, symlink creation may require developer mode or elevated privileges, and path separator differences are not handled by this plain configuration. To roll back, remove the `turbopack.resolveAlias` block or set it to an empty object. A future Next.js version should implement a proper opt-in for external dependency roots; upgrade to that version when available.