Turbopack Phantom Module References Causing Panic

[Slompo-Int]

CRITICAL BUG REPORT: Turbopack Phantom Module References Causing Panic

Severity: Critical — Blocks entire development workflowEnvironment: v0 Preview with Next.js 16 + TurbopackStatus: Consistently reproducible — Persists after multiple cache clears and file deletions

Summary

Turbopack references deleted middleware files (./middleware.ts and ./lib/supabase/middleware.ts) that no longer exist in the filesystem. The build system attempts to resolve these non-existent files, causing a Turbopack panic and complete dev environment failure. Production builds work fine (clean build environment).

Reproduction Steps

1. Create Next.js 16 project with Turbopack (default)
2. Create middleware.ts (root) and lib/supabase/middleware.ts that import @supabase/ssr
3. Delete both files completely from the filesystem
4. Confirm files are gone: ls middleware.ts lib/supabase/middleware.ts → file not found
5. Run npm run dev
6. Expected: Dev server starts without referencing deleted files
7. Actual: Turbopack panics with "Can't resolve '@supabase/ssr'" error

Error Output

⨯ ./lib/supabase/middleware.ts:1:1
Module not found: Can't resolve '@supabase/ssr'

Import trace:
  Edge Middleware:
    ./lib/supabase/middleware.ts
    ./middleware.ts

FATAL: An unexpected Turbopack error occurred. A panic log has been written to /tmp/next-panic-17d14457cf8d7eb2be7f5d23646a20f9.log.

Turbopack Error: Next.js package not found

Failed Mitigation Attempts

• ✗ rm -rf .next && npm run dev — Phantom references persist
• ✗ turbopackFileSystemCacheForDev: false — No effect
• ✗ Explicit file system deletion + server restart — Files still referenced
• ✗ Multiple full cache clears — Issue persists

Root Cause Analysis

• Files were deleted from filesystem (confirmed via file system queries)
• Turbopack module resolution still references deleted files in import traces
• Edge middleware detection includes phantom file references
• Indicates Turbopack's module dependency graph is not properly invalidated when files are deleted

System Information

• Next.js Version: 16.0.0
• Turbopack: Default (built-in)
• Environment: v0 Preview (v0.app)
• Node.js: Current LTS
• OS: Linux (v0 sandbox)

Panic Log Details

Turbopack version: 0c06f068
Next.js version: 0.0.0
Error: Next.js package not found
Full trace: https://github.com/vercel/next.js/discussions/new?category=turbopack-error-report&title=Turbopack%20Error%3A%20Next.js%20package%20not%20found&body=Turbopack%20version%3A%20%600c06f068%60%0ANext.js%20version%3A%20%600.0.0%60%0A%0AError%20message%3A%0A%60%60%60%0ATurbopack%20Error%3A%20Next.js%20package%20not%20found%0A%60%60%60

Impact

• ❌ Development environment completely non-functional
• ✅ Production builds deploy successfully (unaffected)
• ❌ No viable workaround
• ❌ Blocks team development velocity

Expected Behavior

1. When files are deleted, Turbopack should detect and remove them from module dependency graph
2. Module resolution should not reference non-existent files
3. Dev server should start cleanly without panic
4. Or: Provide a cache invalidation mechanism that properly clears phantom references

Questions for Support

1. Is this a known issue with Turbopack's module resolution in v0?
2. Are there any undocumented cache locations beyond .next/ that need manual clearing?
3. Can this be reproduced in a standalone Next.js 16 project, or is it v0-specific?

[JNEWSP]

This really looks like two different things happening:

1. The expected error after deleting the middleware files:

Module not found: Can't resolve '@supabase/ssr'
from
./lib/supabase/middleware.ts → ./middleware.ts

2. The unexpected part where Turbopack then panics and ends up with:

Turbopack Error: Next.js package not found
Next.js version: 0.0.0

That second error suggests a bug in Turbopack’s module‑graph invalidation when edge middleware files are deleted: it seems to keep references to deleted modules and then gets into a broken state, instead of just throwing a normal “module not found” and recovering.

A couple of ideas that might help confirm this and narrow it down:

• Try the same repro but with a dummy import instead of @supabase/ssr, for example:

  // ./middleware.ts and ./lib/supabase/middleware.ts
  import 'non-existent-middleware-package';

  If deleting those files still produces the same panic, that would confirm this is a generic “deleted middleware file” invalidation issue rather than something specific to @supabase/ssr.

• Check whether this only happens in the Next 16 v0 (app) preview, or if you can also reproduce it in a plain create-next-app project without v0.

• As a temporary workaround, I’ve had more stable behavior by:

  1. stopping the dev server,
  2. deleting the middleware files,
  3. clearing caches with rm -rf .next .turbo,
  4. starting next dev --turbo again.

If you can attach the panic log from /tmp/next-panic-*.log along with the result of the “dummy import” repro, that should give maintainers good data to track down the phantom‑module / stale‑dependency bug.

[JNEWSP]

This really looks like two different things happening:

1. The expected error after deleting the middleware files:

Module not found: Can't resolve '@supabase/ssr'
from
./lib/supabase/middleware.ts → ./middleware.ts

2. The unexpected part where Turbopack then panics and ends up with:

Turbopack Error: Next.js package not found
Next.js version: 0.0.0

That second error suggests a bug in Turbopack’s module‑graph invalidation when edge middleware files are deleted: it seems to keep references to deleted modules and then gets into a broken state, instead of just throwing a normal “module not found” and recovering.

A couple of ideas that might help confirm this and narrow it down:

• Try the same repro but with a dummy import instead of @supabase/ssr, for example:

  // ./middleware.ts and ./lib/supabase/middleware.ts
  import 'non-existent-middleware-package';

  If deleting those files still produces the same panic, that would confirm this is a generic “deleted middleware file” invalidation issue rather than something specific to @supabase/ssr.

• Check whether this only happens in the Next 16 v0 (app) preview, or if you can also reproduce it in a plain create-next-app project without v0.

• As a temporary workaround, I’ve had more stable behavior by:

  1. stopping the dev server,
  2. deleting the middleware files,
  3. clearing caches with rm -rf .next .turbo,
  4. starting next dev --turbo again.

If you can attach the panic log from /tmp/next-panic-*.log along with the result of the “dummy import” repro, that should give maintainers good data to track down the phantom‑module / stale‑dependency bug.