nextjs - 💡(How to fix) Fix Turbopack persistent dev cache OOMs after removing a cached dependency [1 comments, 2 participants]

Summary

Removing a dependency that has been compiled into Turbopack's persistent dev cache (.next/dev/) without clearing the cache causes next dev to hang at Compiling … with sustained ~800% CPU and grow memory until the process is OOM-killed.

rm -rf .next/ followed by pnpm dev resolves it cleanly. The cache appears not to fingerprint against package.json / lockfile content, so a stale graph survives a dependency removal.

To reproduce

Conditions under which I observed this:

1. Next 16.2.4 + Turbopack + pnpm 9.x, Node 24, macOS arm64.
2. App with one or more routes that import @supabase/supabase-js (deep transitive tree: @supabase/postgrest-js, @supabase/realtime-js, @supabase/auth-js, @supabase/storage-js, @supabase/functions-js, plus their deps).
3. pnpm dev. Hit several routes to seed the cache. Cache grew to ~890 MB; find .next -name '*supabase*' | wc -l reported 32 chunks under .next/dev/server/chunks/ and .next/dev/server/chunks/ssr/.
4. Kill next dev.
5. pnpm remove @supabase/supabase-js and remove all source imports of it.
6. pnpm install (no manual cache clear).
7. pnpm dev. Navigate to one of the previously-seeded routes.

Result: Compiling /<route> ... printed once, then nothing. next dev sustains ~800% CPU and RSS grows steadily. Eventually OOM-killed by the OS (16 GB Mac).

rm -rf .next/ between steps 6 and 7 makes the issue go away every time.

Current vs. expected

Current: stale cache entries pointing at deleted modules trigger an unbounded reconciliation pass that holds growing structures in memory, with no error or warning surfaced.

Expected: the cache should either fingerprint against package.json / pnpm-lock.yaml content and self-invalidate when deps change, or detect missing modules during graph load and rebuild from source with a one-line warning. Either is a one-time check at startup.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 22.6.0
Binaries:
  Node: 24.6.0
  npm: 11.5.1
  pnpm: 9.15.0
Relevant Packages:
  next: 16.2.4
  react: 19.2.5
  react-dom: 19.2.5
  typescript: 5.9.3
Next.js Config:
  output: N/A
  turbopack: { root: __dirname }

Reproduction repo

Did not include one. A minimal single-dep variant (single page, import { kebabCase } from 'lodash', seed cache, remove dep, restart) does NOT reproduce the OOM (peak ~120 MB RSS, 200 OK). The bug appears to need a deeper transitive tree (Supabase had ~30 sub-packages) and/or more cached routes than a one-page repro provides. Filing without a repro because the cache-invalidation gap is independently fixable: keying the cache on lockfile content would make the question of how to trigger reconciliation moot.

Notes

• The cache contained chunks like 0tx7_@supabase_postgrest-js_dist_index_mjs_0vgnv1f._.js referencing modules no longer present in node_modules/. Pre-failure, all 32 stale chunks could be found via find .next -name '*supabase*'.
• Adding "postinstall": "rm -rf .next" to package.json is an effective workaround at the project level.
• next dev (default Turbopack) hangs; haven't tested whether the legacy webpack pipeline behaves the same.