Next.js: Subsequent builds of dynamic import chunks have same version watermark

[JulesAU]

I'm not exactly clear on how the cache-busting versioning system works during build, but this is best explained by showing the contents of out/ after next export:

next build; next export; find out

out/_next/17d78cb0-9d1a-4223-a9bf-79d0cef0f5bd
out/_next/17d78cb0-9d1a-4223-a9bf-79d0cef0f5bd/page
out/_next/17d78cb0-9d1a-4223-a9bf-79d0cef0f5bd/page/_error
out/_next/17d78cb0-9d1a-4223-a9bf-79d0cef0f5bd/page/_error/index.js
out/_next/17d78cb0-9d1a-4223-a9bf-79d0cef0f5bd/page/index.js
out/_next/17d78cb0-9d1a-4223-a9bf-79d0cef0f5bd/page/next-page
out/_next/17d78cb0-9d1a-4223-a9bf-79d0cef0f5bd/page/next-page/index.js
out/_next/f944c50066e317d087ce3206aeaf1316
out/_next/f944c50066e317d087ce3206aeaf1316/app.js
out/_next/webpack
out/_next/webpack/chunks
out/_next/webpack/chunks/0
out/_next/webpack/chunks/eb27b953-0c42-4fdf-9fb4-3c3589ca13f7.js

Note our three "watermarks": 17d78cb0-9d1a-4223-a9bf-79d0cef0f5bd, f944c50066e317d087ce3206aeaf1316 and eb27b953-0c42-4fdf-9fb4-3c3589ca13f7.

Now we make some changes to all of our source code, and rebuild:

next build; next export; find out

out/_next/5ebcdb8a-8c43-4e8e-a5d7-f03c92725aba
out/_next/5ebcdb8a-8c43-4e8e-a5d7-f03c92725aba/page
out/_next/5ebcdb8a-8c43-4e8e-a5d7-f03c92725aba/page/_error
out/_next/5ebcdb8a-8c43-4e8e-a5d7-f03c92725aba/page/_error/index.js
out/_next/5ebcdb8a-8c43-4e8e-a5d7-f03c92725aba/page/index.js
out/_next/5ebcdb8a-8c43-4e8e-a5d7-f03c92725aba/page/next-page
out/_next/5ebcdb8a-8c43-4e8e-a5d7-f03c92725aba/page/next-page/index.js
out/_next/ac1275d574cbbc255148deb139cacdac
out/_next/ac1275d574cbbc255148deb139cacdac/app.js
out/_next/webpack
out/_next/webpack/chunks
out/_next/webpack/chunks/0
out/_next/webpack/chunks/eb27b953-0c42-4fdf-9fb4-3c3589ca13f7.js

2 out of 3 changed, but our dynamic chunk remained the same: eb27b953-0c42-4fdf-9fb4-3c3589ca13f7.js

So after upload the browsers' cache (or, say CDN cache) doesn't get busted and so the app is broken for the user.

I assume this is not the intended behaviour?

Just tested with 3.0.0 beta16; and issue still appears.

[arunoda]

2 out of 3 changed, but our dynamic chunk remained the same: eb27b953-0c42-4fdf-9fb4-3c3589ca13f7.js

What do you mean by this?
This can be true if the content of the chunk is the same.

Is it possible to have a sample repo where I can reproduce this issue?

[JulesAU]

Sure - try this: https://github.com/JulesAU/next-test

git clone https://github.com/JulesAU/next-test.git
cd next-test/
npm install
npm run build
find .next/chunks/

And you can see that our dynamic component has been built into (in this case):

.next//chunks/9152bef5-2503-46df-aee1-68c91985783f.js

Now, if we make some changes to that dynamic component:

git checkout b31c71480b1a4530d8a1ce97ed8243b2e2680380

And rebuild it:

rm -rf .next; npm run build

The chunk filename remains the same:

.next/chunks//9152bef5-2503-46df-aee1-68c91985783f.js

Even though the content is most definitely different.

[polovi]

Same problem in latest version of nextjs
Chunks have same addres when content changed and browser cache return old version

[marbemac]

We just ran into this as well - bit us in the ass in production. We're removing all dynamic chunks for now.

[marbemac]

Actually for us it seemed to be a caching issue brought on by https://github.com/zeit/next.js/pull/2788.

Looks like UUID.v4() used to be appended to the dynamic import, but now it's just a md5 hash of the modulePath. Probably just not understanding the full process - where is the unique watermark created for dynamic imports, if the appended UUID is no longer there?

[arunoda]

@marbemac good point in there. We should prefix dynamic imports by the buildId in production. I'll do release ASAP. (possible within 24 hours)

[marbemac]

Using the buildId would mean users would have to re-download all dynamic chunks on every deploy - would it be possible to use a content based watermark? Such that the path is only updated if the contents inside the dynamic import are changed?

[arunoda]

@marbemac that's also doable. But I'd wait that for another task since we need to test more on that.
My current goal is to do a hotfix on this issue.

[polovi]

@arunoda quick fix will be great

for now a i'm bypassing it over config.output.chunkFilename = '[name]-[chunkhash].js' in custom next config

[marbemac]

Sure, no problem, a quick fix would be great - this is a nasty little bug because you don't catch it until subsequent deploys in a production setting with caching enabled. We've reverted to 3.0.3 for the time being.

[arunoda]

Anyway, I'll try to get the hash if possible?

[rauchg]

Thanks for the help describing this issue @JulesAU, @polovi and @marbemac! We're on it.

[arunoda]

@polovi @marbemac If possible try this PR: https://github.com/zeit/next.js/pull/2873

[polovi]

@arunoda seems it works on chunk cache problem and add generated uuid in path. Is changed every time i build app (whether or not there is a change in dynamic component)

[arunoda]

@polovi That's the behaviour and it's similar to what we had previous. (Add a UUID as the name).
UUID gives us some other issues, that's why I went for this.

[arunoda]

I want address to do better caching soon.

[arunoda]

I just deployed 3.2.1 with a fix for this.

[marbemac]

Thanks for the quick turnaround Arunoda! Will let you know how it works for us next week.

[lock[bot]]

This thread has been automatically locked because it has not had recent activity. Please open a new issue for related bugs and link to relevant comments in this thread.