Fix Next.js 16 Compile Stuck on Turbopack Dev Server
Iwan Efendi3 min
How I debugged and fixed the Next.js 16 Turbopack dev server that kept crashing at 'Compiling /[locale]' after migrating to Tailwind CSS v4.
Baca dalam IDID
After successfully migrating SnipGeek from Tailwind CSS v3.4.1 to v4 and Next.js 15 to 16, I hit a frustrating wall: the dev server kept dying silently at
Every time I ran
No compilation error. No helpful log. The process simply vanished.
Before finding the root cause, I went through several failed attempts that are worth documenting.
Sometimes it was, sometimes it wasn't. Killing the orphan process and restarting didn't help. The server would start, then crash again at compilation.
The breakthrough came when I took a more systematic approach:
After all three fixes, the server compiled successfully:
The compilation took 7.8 seconds—which is why it appeared to be stuck. It was actually working, but running out of memory before it could finish.
For more details on resolving silent failures, check out How to Fix AI Build Failed Logs to improve your workflow when local compiler pipelines break. If your server compiles successfully but page loading still stutters, How to Optimize Next.js Image Scrolling for Better UX offers advice on tuning CSS render parameters.
I updated the
Three factors combined to create the silent crash:
Q: What are the main error signatures of an Out Of Memory (OOM) crash in Turbopack?
A: The primary signature is a silent crash with exit code
○ Compiling /[locale] ... with exit code 1. No error message. No stack trace. Just... dead.
This note documents the full debugging journey—every wrong turn and the final fix—so you don't have to waste hours on the same problem.
The Symptom
npm run dev, the Turbopack server would start fine:
▲ Next.js 16.1.6 (Turbopack)
- Local: http://localhost:9003
✓ Starting...
✓ Ready in 1552ms
○ Compiling /[locale] ...
# ← process dies here, exit code 1The Wrong Turns
Attempt 1: Restarting the Server
The most obvious first step. Kill the process, restart. Same result every time—stuck at the same point.Attempt 2: Checking Port Conflicts
I suspected port9003 was already in use:
netstat -ano | findstr :9003Attempt 3: Reverting Git Commits
I even rolled back to an older commit (c640944 — the pre-migration backup) to rule out code changes. The older Tailwind v3 codebase had its own issues with the newer dependencies, so this wasn't a viable path either.
Don't Panic-Revert
Rolling back multiple commits without understanding the root cause can create more problems than it solves. Always diagnose first.
Finding the Root Cause
1
Cleared the Stale Turbopack cache from the migration could have been causing compilation to choke.
.next cache completely.Remove-Item -Recurse -Force .next2
Increased Node.js memory allocation.The
/[locale] route in SnipGeek is heavy—it imports Firebase, Radix UI, Framer Motion, Recharts, and many other dependencies. The default Node.js heap size (~1.7 GB) was not enough for Turbopack to compile everything.$env:NODE_OPTIONS="--max-old-space-size=4096"
npx next dev --turbopack -p 90033
Fixed the proxy export name.Next.js 16 renamed
middleware to proxy. The file was already renamed to src/proxy.ts, but the exported function was still called middleware:// ❌ Before (crashes silently)
export function middleware(request: NextRequest) { ... }
// ✅ After
export function proxy(request: NextRequest) { ... }✓ Ready in 2.3s
○ Compiling /[locale] ...
GET / 200 in 9.2s (compile: 7.8s, proxy.ts: 82ms, render: 1249ms)The Permanent Fix
dev script in package.json to always allocate sufficient memory:
{
"scripts": {
"dev": "cross-env NODE_OPTIONS=--max-old-space-size=4096 next dev --turbopack -p 9003"
}
}Why This Happened
| Factor | Detail |
|---|---|
| Turbopack + large route | The /[locale] layout imports 15+ heavy packages (Firebase, Radix UI, Framer Motion, etc.) |
| Default memory limit | Node.js defaults to ~1.7 GB heap, insufficient for bundling all dependencies |
| Silent OOM | Turbopack doesn't surface out-of-memory errors clearly—the process just exits with code 1 |
Quick Diagnostic
If your Next.js 16 dev server dies silently during compilation, the first thing to try is increasing memory:
NODE_OPTIONS=--max-old-space-size=4096. This alone solves many Turbopack compilation crashes.Key Takeaways
- Silent exit code 1 during Turbopack compilation is often an OOM issue. Always check memory allocation first.
- Clear
.nextcache after major migrations. Stale cache can cause unpredictable compilation failures. - Next.js 16 requires
proxyexport, notmiddleware. The error message for this is clear, but it can get buried if other issues crash the server first. - Don't panic-revert. Diagnose systematically before rolling back commits.
FAQ
1 or 137 (SIGKILL) directly after printing ○ Compiling /[locale] ... or during high cpu activity. No exception error output is printed to the terminal because the operating system or Node.js runtime terminates the process immediately before a stack trace can be output.
Q: Should I use Turbopack or stick with Webpack for local development?
A: Turbopack is highly recommended because it is significantly faster than Webpack (often 5x to 10x faster startup and HMR times in large codebases). However, because Turbopack is written in Rust and runs native compilation, its memory profile can spike higher during initialization. If memory is tight, allocating 4096 using NODE_OPTIONS mitigates this issue completely.
Q: How do I completely clear the local Next.js cache when troubleshooting compile loops?
A: You must delete the .next directory located at the root of your project. If you are on Linux or macOS, run rm -rf .next. If you are using Windows PowerShell, run Remove-Item -Recurse -Force .next. This forces the compiler to re-fetch and rebuild your entire module dependency graph from scratch.
Q: What is the difference between middleware.ts and proxy.ts in Next.js 16?
A: Next.js 16 introduces changes to structural layouts. The standard routing interceptor file, previously called middleware.ts at the root, has been restructured under the proxy namespace to handle redirects and headers natively, requiring a named proxy export instead of a middleware default or named export.
References
- Next.js Compilation Troubleshooting Guide — Official troubleshooting guidelines for fixing compile issues and memory allocation limits.
- Turbopack Official Documentation — Details on Turbopack architecture, caching strategies, and configuration options.
- Node.js Command Line Options — Details on
max-old-space-sizememory configurations and limits. - Tailwind CSS v4 Migration Guide — Technical breakdown of the Tailwind v4 migration steps and compiler updates.
Topics
Topics in this note
Explore related ideas through the topics connected to this note.
Share this article
Discussion
Preparing the comments area...