nextjs - 💡(How to fix) Fix Turbopack inferred parent root can trigger macOS VM compressor exhaustion and watchdog panic

Link to the code that reproduces this issue

This appears closely related to #92978, but the observed failure mode on macOS was more severe: the machine entered VM compressor exhaustion and then rebooted/panicked via watchdog.

To Reproduce

The reduced condition is:

1. Use a Next.js 16.2.x application where next dev runs with Turbopack.
2. Let Next.js infer the workspace/root from lockfiles instead of explicitly setting turbopack.root.
3. Have the inferred root resolve to a parent directory that contains many unrelated files/projects.
4. Start next dev.
5. Open a browser route that triggers compilation and filesystem watching/resolution.

In the affected local setup, explicitly constraining turbopack.root to the application directory was the mitigation.

Current vs. Expected behavior

Current behavior:

When the inferred Turbopack root expands to a large parent directory, the dev server can create enough filesystem watching/resolution/cache pressure to drive memory pressure very high. In the observed macOS case this escalated beyond a normal Node.js process crash:

panic: watchdog timeout: no checkins from watchdogd in 94 seconds
Compressor Info: 89% of compressed pages limit (OK) and 100% of segments limit (BAD) with 48 swapfiles and OK swap space

System logs shortly before the reboot/panic showed VM compressor pressure and jetsam activity:

memorystatus: killing due to "vm-compressor-space-shortage"
memorystatus: System is unhealthy
"compressor_exhausted": 1
JETSAM_REASON_MEMORY_VMCOMPRESSOR_SPACE_SHORTAGE

Expected behavior:

• A misdetected or overly broad workspace root should fail fast or produce a blocking error before Turbopack starts watching/resolving a very large parent tree.
• Multiple lockfiles / suspicious parent-root inference should not lead to unbounded memory growth.
• Turbopack should have a memory/resource guardrail for dev-server workers/watchers/cache work.
• If turbopack.root is set explicitly, all downstream resolver and watcher behavior should strictly honor it.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin 25.5.0 / macOS 26.5
  Memory: 16 GB

Binaries:
  Node: 24.15.0
  npm: 11.x

Relevant Packages:
  next: 16.2.x
  react: 19.2.x
  react-dom: 19.2.x
  tailwindcss: 4.x

Next.js Config:
  The problematic configuration relied on inferred root.
  Mitigation was setting turbopack.root explicitly to the app directory.

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

Turbopack, next dev, filesystem root detection, filesystem watching, memory usage

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

next dev (local)

Additional context

This looks like a combination of:

1. Next.js root inference selecting a parent directory based on lockfiles.
2. Turbopack using that broad root for module resolution / filesystem watching / dev cache.
3. A large parent directory tree causing memory and VM compressor pressure.

The closest existing report I found is #92978. The important difference here is the macOS failure signature: instead of only a Node OOM or frozen dev server, the system reached VM compressor segment exhaustion and then a watchdog reboot/panic.

The docs suggest collecting a Turbopack trace for performance or memory issues:

NEXT_TURBOPACK_TRACING=1 next dev