Originally created by: Akarsh-Hegde
next dev --turbopack crashes on startup with:
TurbopackInternalError: Invalid distDirRoot: ".next". distDirRoot should not navigate out of the projectPath.
ui/next.config.ts sets output: 'standalone' unconditionally. Combined with the pinned outputFileTracingRoot / turbopack.root (both ui/), Next 16.2's Turbopack mis-resolves the dev distDir and aborts. This blocks the local hot-reload dev server (dev-start.sh window [#3] and cd ui && npm run dev).
Gate output: 'standalone' on the build phase (PHASE_PRODUCTION_BUILD), not process.env.NODE_ENV:
const nextConfig = (phase: string): NextConfig => ({
...
output: phase === PHASE_PRODUCTION_BUILD ? 'standalone' : undefined,
...
})
Plus a second line of defence on the dev script:
"dev": "env -u NODE_ENV next dev --turbopack -p 3939"
NODE_ENVThe actual upstream of the panic is running next dev with a non-standard NODE_ENV (including production) exported in the shell — that double-joins the dev distDir (.next/dev/dev) and corrupts the Turbopack cache (vercel/next.js#87881). A process.env.NODE_ENV === 'production' gate would still emit standalone in exactly that scenario and keep crashing. PHASE_PRODUCTION_BUILD is true only during next build, so it's immune; env -u NODE_ENV strips a stray value so the corruption can't happen at all.
Supersedes [#274], which used the weaker
NODE_ENVgate.
npm run build runs under PHASE_PRODUCTION_BUILD → standalone bundle still emitted exactly as before. package-release.sh / install-from-bundle.sh are unaffected.next dev runs under PHASE_DEVELOPMENT_SERVER → no standalone tracing → Turbopack boots clean.npm run build → succeeds, .next/standalone/server.js emitted (standalone still active for production).next.config.ts.🤖 Generated with Claude Code
Ticket changed by: Akarsh-Hegde
Originally posted by: adityaharishch
🎉 This PR is included in version 1.52.3 🎉
The release is available on:
v1.52.3Your semantic-release bot 📦🚀