Build Cache with Webpack 5 and PostCSS-PurgeCSS

[toviszsolt]

What version of Next.js are you using?

11 and 12 (only with Webpack 5)

What version of Node.js are you using?

14 and 16

What browser are you using?

does not matter

What operating system are you using?

Windows 10

How are you deploying your application?

SSG and/or Vercel Deploy via GitHub

Describe the Bug

The issue only occurs with Webpack 5. With Webpack 4 everything is fine.

• Using external CSS library from node_modules with @fullhuman/postcss-purgecss PostCSS plugin.
• PostCSS and PurgeCSS work well.
• After the first next build, the purged CSS files are cached during the build.
• If I do not modify the CSS source files, BUT change any class name in any component, the build cache is not updated.

Example:

• CSS library contains the following CSS selectors: color-red, color-blue, color-green
• Set color-red class name on a html tag.
• !! On next build won't purge color-red and will be cached
• !! On next build will be purge color-blue, color-green and won't be cached
• Change the class name of the html tag from color-red to color-blue
• After next build the color-blue selector doesn't exists in css files

Expected Behavior

Cache is always good, but should resolve that cache is updated when needed with Webpack 5.

To Reproduce

The issue only occurs with Webpack 5. With Webpack 4 everything is fine. See Example above.

[github-actions]

Please verify that your issue can be recreated with next@canary.

Why was this issue marked with the please verify canary label?

We noticed the provided reproduction was using an older version of Next.js, instead of canary.

The canary version of Next.js ships daily and includes all features and fixes that have not been released to the stable version yet. You can think of canary as a public beta. Some issues may already be fixed in the canary version, so please verify that your issue reproduces by running npm install next@canary and test it in your project, using your reproduction steps.

If the issue does not reproduce with the canary version, then it has already been fixed and this issue can be closed.

How can I quickly verify if my issue has been fixed in canary?

The safest way is to install next@canary in your project and test it, but you can also search through closed Next.js issues for duplicates or check the Next.js releases.

My issue has been open for a long time, why do I need to verify canary now?

Next.js does not backport bug fixes to older versions of Next.js. Instead, we are trying to introduce only a minimal amount of breaking changes between major releases.

What happens if I don't verify against the canary version of Next.js?

An issue with the please verify canary that receives no meaningful activity (e.g. new comments that acknowledge verification against canary) will be automatically closed and locked after 30 days.

If your issue has not been resolved in that time and it has been closed/locked, please open a new issue, with the required reproduction, using next@canary.

I did not open this issue, but it is relevant to me, what can I do to help?

Anyone experiencing the same issue is welcome to provide a minimal reproduction following the above steps. Furthermore, you can upvote the issue using the 👍 reaction on the topmost comment (please do not comment "I have the same issue" without repro steps). Then, we can sort issues by votes to prioritize.

I think my reproduction is good enough, why aren't you looking into it quicker?

We look into every Next.js issue and constantly monitor open issues for new comments.

However, sometimes we might miss one or two due to the popularity/high traffic of the repository. We apologize, and kindly ask you to refrain from tagging core maintainers, as that will usually not result in increased priority.

Upvoting issues to show your interest will help us prioritize and address them as quickly as possible. That said, every issue is important to us, and if an issue gets closed by accident, we encourage you to open a new one linking to the old issue and we will look into it.

Useful Resources

• How to Contribute to Open Source (Next.js)
• How to create a Minimal, Complete, and Verifiable example
• Reporting a Next.js bug
• Next.js Triaging issues

[varenya]

I am looking into this one.

[varenya]

I tried to reproduce using the following config https://purgecss.com/guides/next.html#customize-postcss-configuration-next-js-9-3 but its working as expected.

Can you please provide an example as per the instructions :

https://stackoverflow.com/help/minimal-reproducible-example

[toviszsolt]

Sorry I have very little time, December and January are a madhouse in the business world.
Now I'm working on a regular CRA project and a problem has come up, I think the cause of the problem will be similar.

• Webpack creates css files with a hash in the filename ( looks to be CRC hash).
• If any postbuild script modifies the css file, the hash is not changed.
• Since the hash is not changed the browser cache will serve the old css file.
• In PWA projects with an Offline First strategy, it is almost impossible to update the browser cache.

[varenya]

Looks like this is an issue with Webpack 5 instead of next. Perhaps raising it there would make sense.

[toviszsolt]

If you think about it, I think you will find that the problem is not with Webpack, and I would call this an anomaly.
So, there doesn't seem to be a problem with either Webpack or Next, but there is an anomaly on top of the stack.
Finally, let's close that issue. I will look into the anomaly one day when I have more time.

[github-actions]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.