You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Take note of the last two filenames in .next/static/chunks/ - reactPlayerYouTube.[contenthash].js and webpack.[chunkhash].js
Update to next.js v15.3.0
Run npm build again.
Go look at those same two file names again.
Current vs. Expected behavior
What you should see is that the hash for reactPlayerYouTube has changed, but the hash for webpack has not, even though the content ofwebpack.[chunkhash].js has changed.
What this has resulted in is that we pushed an update to next.js to production. Any user that had previously visited the site has webpack.[chunkhash].js cached in their browser, because it gets a cache-control header of public, max-age=31536000, immutable since it's supposed to get a new hash when content changes.
But as you can see it doesn't. So for those users that already had it cached, their cached version is referencing a reactPlayerYouTube.[contenthash].js file that no longer exists on our server, since we wipe .next on deploy.
This is happening because in next.js's webpack.config.js there is this:
filename: isNodeOrEdgeCompilation
? dev || isEdgeServer
? `[name].js`
: `../[name].js`
: `static/chunks/${isDevFallback ? 'fallback/' : ''}[name]${
dev ? '' : appDir ? '-[chunkhash]' : '-[contenthash]'
}.js`,
// This saves chunks with the name given via `import()`
chunkFilename: isNodeOrEdgeCompilation
? '[name].js'
: `static/chunks/${isDevFallback ? 'fallback/' : ''}${
dev ? '[name]' : '[name].[contenthash]'
}.js`,
filename is using [chunkhash] for app router, while chunkFilename is using [contenthash].
If filename was using [contenthash] as well, I believe this would not be a problem. I may be wrong in my diagnoses, but this is certainly an issue and permanently breaks the site for repeat visitors until we ship something that gets [chunkhash] to change for that file.
We have the same issue. Everything is working perfectly with 15.2.5 but when we update to 15.3.2, some pages fail with the missing chunk error (as described, is using the old name of the chunk file).
On our case looks like the chunk is a component loaded with dynamic + { ssr: false } (just in case it helps). If we remove the component from the page or change some code on the page, then it works.
Link to the code that reproduces this issue
https://github.com/MartinDavi/nextjs-reproduction
To Reproduce
npm install
npm run build
.next/static/chunks/
-reactPlayerYouTube.[contenthash].js
andwebpack.[chunkhash].js
npm build
again.Current vs. Expected behavior
What you should see is that the hash for
reactPlayerYouTube
has changed, but the hash forwebpack
has not, even though the content ofwebpack.[chunkhash].js
has changed.What this has resulted in is that we pushed an update to next.js to production. Any user that had previously visited the site has
webpack.[chunkhash].js
cached in their browser, because it gets acache-control
header ofpublic, max-age=31536000, immutable
since it's supposed to get a new hash when content changes.But as you can see it doesn't. So for those users that already had it cached, their cached version is referencing a
reactPlayerYouTube.[contenthash].js
file that no longer exists on our server, since we wipe.next
on deploy.This is happening because in next.js's
webpack.config.js
there is this:filename
is using[chunkhash]
for app router, whilechunkFilename
is using[contenthash]
.If
filename
was using[contenthash]
as well, I believe this would not be a problem. I may be wrong in my diagnoses, but this is certainly an issue and permanently breaks the site for repeat visitors until we ship something that gets[chunkhash]
to change for that file.Provide environment information
Which area(s) are affected? (Select all that apply)
Webpack
Which stage(s) are affected? (Select all that apply)
next build (local), Other (Deployed)
The text was updated successfully, but these errors were encountered: