Affected version
Reports that share this version, grouped in one feed.
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.
After an ISR revalidation turns a route that was prerendered as a fully static redirect() into a partially prerendered page, client-side navigations fail: RSC requests receive the static shell only (or 404), never resume, causing React error 412 and a full page reload. The build-time prefetchDataRoute pins the route to serve prebuilt static RSC content, ignoring the new postponed cache entry.
In Next.js 16.3.x with output: 'standalone', next-i18next.config.js is not copied into .next/standalone, causing 500 errors because next-i18next cannot locate its config at runtime. Regression from 16.2.12.
Next.js 16.3 introduced a regression where route handler modules are not eagerly evaluated at startup, causing the first request to a route handler to pay full module evaluation cost. This increases cold start latency and p99 for deployments.
Next.js Turbopack production build consumes the entire 4 GB container memory when compiling ~12,000 client modules, causing continuous cgroup limit hits and either a kernel OOM kill or a timeout without forward progress. The issue affects 16.3.2 and 16.4.0-canary.4.
In Next.js 16.3.0 and later with optimisticRouting enabled by default, navigation from a dynamic segment to another dynamic route can fail to reset scroll position. This occurs when the app has a root parallel slot with a catch-all page returning null, alongside a sibling dynamic route. Predicted route trees reify stale params, causing a server mismatch and retry that consumes the scroll-ref on an empty catch-all leaf, so the new page retains the previous scroll offset.
Next.js dev server (Turbopack) fails to match routes that are children of a dynamic segment nested inside route groups, returning instant 404 for the entire session. The issue is probabilistic, occurs under module graph load, and is repaired by any file event under app/. Production builds are unaffected.
When a module using next/dynamic is imported by both Pages Router and App Router, ReactLoadablePlugin writes the App Router webpack module id into react-loadable-manifest.json, causing Pages Router client bundle to request the wrong dynamic chunk id and fail hydration with React error #418.
Next.js 16.x with Turbopack and pnpm emits a false 'Module not found' warning for styled-jsx/style.js during Pages Router builds, even though the build succeeds and the file is traced.
Using styled-jsx in a Pages Router application with pnpm triggers a false 'Module not found' warning during Turbopack builds. The warning occurs because Turbopack's external tracing attempts to resolve styled-jsx/style.js from the project root, but pnpm's strict node_modules layout does not hoist styled-jsx to the root. The build still succeeds and the file is correctly traced via Next.js's own require hooks.