CSS Module chunking isn't working as intended - duplicates.

[ShanonJackson]

Bug report

Love the library, love zeit just though i'd use your website as an example.
Chunks contain duplicate class names resulting in weird/unexpected ordering of css. The example provided here doesn't show the ordering breaking however in my own application classes specificity can change depending on the order of classes duplicated.

Describe the bug

Chunks contain duplicate classes across multiple chunks.

To Reproduce

I don't have a reproduction repository as i don't have time but looking at zeit.co i can tell its using Next 9.3+ so therefore the reproduction is simple look at your own website and inspect this element "tooltip container"

Steps to reproduce the behavior, please provide code snippets or a repository:

1. Go to zeit.co
   2: inspect recent activity text
   3: find span with class "tooltip_container"
   look at how many duplicate class names are applied.

Expected behavior

css classes are not duplicated across chunks

[hmillison]

I am having the same issue with my project. Each page chunk has duplicates of the same css module css. Then as you navigate between routes, it loads the same class multiple times, which creates specificity problems.

[fabinppk]

I am having this problem to.
Chunks contain duplicate classes across multiple chunks.

[rjoaopereira]

I just wanted to add a little more info that may be helpful.
I have a myriad of problems regarding CSS with nextjs. They are related to how nextjs includes css in the several chunks.

Note: to help with debugging I limited the number of chunks to 1.

When I include the same components in the different pages, no chunk is created.

Page                                  Size     First Load JS
┌ λ /                                 7.08 kB         308 kB
├   /_app                             56.4 kB         301 kB
├ λ /application-summary              11.9 kB         313 kB
├ λ /create-application/[id]          1.81 kB         303 kB
└ λ /edit-request/[id]                1.2 kB          302 kB
+ First Load JS shared by all         301 kB
  ├ static/pages/_app.js              56.4 kB
  ├ chunks/styles.cd31ca.js           238 kB
  ├ runtime/main.e62949.js            5.92 kB
  ├ runtime/webpack.24868d.js         785 B

When I remove a component from the index page which is also present in _app.js a chunk is created

Page                                                          Size     First Load JS
┌ λ /                                                         7.25 kB         312 kB
├   /_app                                                     64.7 kB         304 kB
├ λ /application-summary                                      11.9 kB         316 kB
├ λ /create-application/[id]                                  1.81 kB         306 kB
└ λ /edit-request/[id]                                        1.2 kB          306 kB
+ First Load JS shared by all                                 304 kB
  ├ static/pages/_app.js                                      64.7 kB
  ├ chunks/styles.12b5f0.js                                   233 kB
  ├ runtime/main.e62949.js                                    5.92 kB
  ├ runtime/webpack.24868d.js                                 785 B
  ├ chunks/static/<buildId>/pages/_app.js.50c480da.chunk.css  3.99 kB

I would not expect this to happen as _app is core to the application and should be in the main css bundle.

This breaks stuff because:

• _app.js.50c480da.chunk.css contains class a and class b which style the same component. b overrides a in some parameters
• styles.12b5f0.js contains class a (the base class)
• _app.js.50c480da.chunk.css is loaded after the styles.12b5f0.js

class a gets applied again and some parameters get overridden again making the component display incorrectly.

Should _app.js styles always be declared first in the dom?

I have this problem in all pages and I'm juggling components between _app.js and the pages in order to have components display correctly.

[fabinppk]

Notthing here, in my project the problem still persist.

Someone fixed the problem in your personal project?

[Timer]

This has been resolved on next@canary, please upgrade!

[alexandre-marchina]

@Timer thanks for the heads up.

Is there any more details in what was fixed to resolve this? In our particular case (we're using next-css and next-sass, not the built-in css build) we're still experiencing the same bug. Perhaps with more details we can figure out some similarities with our scenario. Maybe something exclusively altered in the built-in css build config that needs to be "replicated" in the next-css usage?

I'll try to create a reproduction repo if there's intention in trying to resolve this in those particular settings (using these plugins and not the built-in). Just to clarify in a short way, in our scenario it would be a massive change in many projects to adapt to the built-in css characteristics (css modules coming from node_modules, shared global css and all)

[Timer]

This fix requires the built-in CSS support and isn't translatable to @zeit/next-css, which is legacy and soon-to-be deprecated!

[mycolaos]

@Timer sorry, I don't understand, what we should do then? I use @zeit/next-stylus and have the same issue. Should we migrate to custom solutions?

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.