Framework
Reports that share this framework, grouped in one feed.
Next.js 16 Turbopack builds fail to include module IDs for ssr:true dynamic components declared in pages/_app.tsx in the __NEXT_DATA__.dynamicIds array. This causes client-side hydration mismatches, discarding server-rendered markup for persistent site chrome (header/footer/cookie banner) and breaking SSR/SEO for those sections.
Next.js 16 with Turbopack generates external module references with content-based hashes that depend on the node_modules directory structure at build time. When deploying to a different environment and reinstalling dependencies (especially with pnpm symlinks), the hashes no longer match the installed packages, causing the production server to fail to start with 'Cannot find module' errors.
When a compile pipeline change (e.g. turbopack.rules loader, reactCompiler) invalidates most of the module graph, `next build` over an existing `.next/cache` is significantly slower and uses more memory than a cold build, often causing OOM on constrained CI. The persistent cache retains stale entries during rebuild and lacks mass-invalidation fallback.
When middleware adds Set-Cookie headers to a response for a prerendered static page, Next.js preserves the page's original Cache-Control: s-maxage=31536000. Shared CDNs that obey s-maxage may cache and serve the response including sensitive Set-Cookie headers to other users, causing cross-user authentication token leakage.
Turbopack dev server consumes ~16 MB × number of previously compiled pages for each subsequent route handler compilation. Ordering matters: requesting handlers before pages avoids the blow-up. Regression introduced in 16.3.0-canary.101.
Turbopack's static analysis incorrectly treats the first argument of child_process.fork() as a module import, causing build failures when the argument is a dynamic path or absolute literal.
Next.js output: 'standalone' file tracing fails to include shared libraries loaded at runtime via dlopen by native addons, causing production crashes (e.g., sharp's libvips). Build succeeds silently; failure occurs only at runtime.
When a route that calls redirect() behind Suspense is retained in a hidden React Activity (with cacheComponents enabled), the streamed __next-page-redirect DOM marker remains in the document. The navigate-reducer uses a document-wide getElementById check, so any subsequent same-origin Link click from the active route triggers a hard navigation instead of an SPA transition.
In Next.js 16.2.10, when using `next start`, page renders are correctly compressed by the built-in `compression` middleware, but all Route Handler responses (including static/prerendered metadata routes and dynamic route handlers) are sent without any `Content-Encoding`. This occurs even when the response body is well above the 1KB compression threshold and the content type is compressible (e.g., `application/xml`). The issue violates the official documentation's promise that Next.js compresses "rendered content and static files" by default, leading to wasted bandwidth and degraded performance for sitemaps, JSON APIs, and other large Route Handler responses in self-hosted environments.
Non-atomic writes in MultiFileWriter.append() can leave partial or invalid JSON in .next/cache/fetch-cache under concurrent writes; fix by writing to a temporary file and atomically renaming it into place.
When using a nonce-based strict CSP, Next.js App Router fails to add the nonce attribute to the parser-inserted <script> tag for Suspense boundary chunks (loading.tsx, template.tsx, error.tsx). This causes the script to be blocked by 'strict-dynamic' on full page loads, leading to console violations and potentially broken client-side functionality.
When htmlLimitedBots is set to /.*/ and cacheComponents/partialPrefetching are enabled, RSC prefetch responses bypass the PPR shell (no x-nextjs-postponed). The client still chooses the PPR fetch strategy, stores the full concrete page under a param-blind shell vary path, and sibling prefetches overwrite each other. Soft navigation then renders the wrong sibling page (e.g., /item/alpha shows Item delta). Affects Next.js 16.3.3 production; not reproducible on 16.4.0-canary.0.
When a Server Action is bound with .bind() inside a Client Component and used as a form action, submitting the form with JavaScript disabled leaves the browser pending indefinitely. The server executes the action, but the returned state is never rendered. Binding the action in a Server Component and passing it as a prop works correctly.
A never-settling RSC fetch promise stored in the segment cache during a stalled navigation poisons subsequent navigations to the same route. With staleTimes.dynamic > 0, the poisoned entry suppresses all requests for the stale window, and even after recovery the navigation remains dead due to React staying suspended on the stale thenable. Requires full page reload.
Calling `after()` arms the current work-unit store, causing the `phase` to be flipped to `'after'` on response close. If the page component later resumes from an await and calls `headers()` or `cookies()`, it gets rejected with E1378, even though the request data is still available. The error is non-deterministic and depends on a race between client disconnect and async continuation.
When runtimeServerDeploymentId is enabled and a build artifact is served under a different deployment ID, the navigation build ID embedded in prerendered flight payloads remains the build-time ID. This causes client-side skew detection (responseBuildId !== getNavigationBuildId()) to trigger an MPA fallback on every client navigation, resulting in an infinite hard-reload loop.
With experimental.inlineCss enabled, the same global CSS text appears three times in prerendered HTML documents: once as a <style> tag and twice in the RSC flight payload. The full flight segment (_full.segment.rsc) re-serializes the hoistable stylesheet instead of reusing the already-emitted row, causing roughly 21% larger prerendered pages and unnecessary ISR write units.
With experimental.inlineCss enabled, the full global stylesheet is embedded three times in every prerendered page: once in the SSR <style> tag, once in the RSC payload segment seed data (documented limitation), and a third time under the GlobalError entry because getGlobalErrorStyles passes a fresh empty Set as injectedCSS to createComponentStylesAndScripts, causing re-inlining of all root layout styles. This significantly inflates HTML size (e.g., ~1.3MB extra per page for a 435KB Tailwind sheet), increasing parse/memory cost and ISR write units.
When using a Git worktree with node_modules symlinked to the primary checkout, running `next dev` with Turbopack triggers an internal panic: "Symlink node_modules could not be resolved: the symlink target leaves the filesystem root or its parent directory could not be resolved". The development server exits before serving the application. This affects parallel AI-assisted coding sessions that share dependencies across worktrees.
Next.js 16.3.x treats dynamic metadata routes with `generateStaticParams` as static metadata files, collapsing `app/[lang]/sitemap.ts` to `/-/sitemap.xml` and dropping per-locale sitemaps.
split_module mixes group indices and compacted module positions; empty groups cause off-by-one leading to out-of-bounds panic in module_fragments/graph.rs:746.
When middleware.ts exists, Next.js normalizes _next/data URLs before config redirects run, causing redirects to match internal data requests and return props from the wrong page. This breaks client-side navigation, while the absence of middleware avoids the issue.
Client-side navigation through a proxy that responds with a 308 redirect preserves the previous page's scroll position, leaving the new page scrolled down instead of at the top.
In Next.js Pages Router, during a shallow navigation, Router.getRouteInfo() may return a cached { __appRouter: true } prefetch marker instead of actual route info, leading to undefined Component and pageProps, crashing _app and preventing navigation.
In Next.js dev, when a prerendered page is activated while the HMR WebSocket is still in CONNECTING state, the client enters an infinite reconnect loop. This prevents page hydration and floods the server with repeated /_next/hmr upgrade requests.
Next.js dev server using rspack panics and aborts when error overlay or browser log forwarding requests original stack frames during a rebuild, due to stale compilation handle aliasing the in-progress compilation.
Next.js dev server retains ~90 MB per edit of a Server Component due to unbounded growth of Node's generatedSourceMapCache and React's fakeFunctionCache. Inline data URL source maps and line/column-dependent keys cause permanent cache entries, leading to OOM crashes.
In Route Handlers, calling cookies() inside after() returns the inbound cookie snapshot instead of the mutated values because the mutable cookie jar is not synchronized before after() switches the work unit phase.
The Edge Runtime process polyfill in Next.js defines process.getBuiltinModule as a throwing stub, violating Node's optional API contract. Packages such as js-bson that use feature detection (e.g., `if (globalThis.process?.getBuiltinModule)`) call the stub and trigger a runtime error, causing 500 errors in edge routes.
When using next/image with a relative src that returns a 302 redirect to an external image, the built-in image optimizer does not follow the redirect and returns a 500 Internal Server Error, while a native <img> displays correctly.