Affected version
Reports that share this version, grouped in one feed.
When using MapLibre GL v6 with Next.js Turbopack, the generated worker file contains an import for 'maplibre-gl-shared-dev.mjs', but the emitted file has a hash suffix, causing the worker to fail with 'Worker failed to load'.
When prefetching the index page of an optional catch-all dynamic route, the client caches the __PAGE__ entry under a fallback slug. Subsequent navigation to a sibling dynamic path reuses this cached entry without issuing a new request, causing the wrong page content to be displayed.
After upgrading to Next.js 16.3.8, deployments that patch the existing .next directory in place (rather than recreating it) leave stale route-cache entries, causing 404s for CSS/JS assets. The root cause is that the route-cache key no longer includes a build identifier, so cached entries from the previous build remain valid after a new deploy.
Next.js 16.3.8 introduced a regression where the route-cache key no longer depends on the build ID. In non-atomic in-place deployments that patch the .next directory without clearing .next/server/route-cache, stale cache entries reference old hashed assets, causing 404s for CSS and JS files after deployment.
After an in-place deployment that patches the .next directory without clearing runtime caches, Next.js 16.3.8 and 16.4.0-canary.60 reuse stale route-cache entries, causing 404s for CSS and JS assets. The regression is linked to PR #99482, which changed the route cache key to no longer depend on the build output.