vite: CSS Modules - composed styles are duplicated

I think this issue should be fixable without processing all CSS files at once.

The problem here is that when a CSS Module is imported and it has a composes, Vite outputs all CSS to a single style element. This is the bug. Vite should output multiple style elements, one for each module. And, if a module of the same name has already been injected then simply do not output it again. After this there would be no more duplication of selectors. (Of course I’m no expert in Vite internals, behavior, nor limitations.)

I would like to see this fixed since I’m moving to Storybook 7 with Vite. This issue breaks our current code architecture. Many of our CSS Modules have zero specificity selectors in order to have no issues on consumer side of component library, avoiding potential issues with CSS file loading order. The existence of this bug forces me to increase specificity selectively based on whether a CSS Module uses composes or not. This will also force me to release a new major version of the library as increasing specificity is a potential breaking change. Also, working around this Vite composes issue will be extra mental load that nobody should be dealing with.

I think one of the reasons this issue does not come up that often is that you will mostly notice this issue if you are a veteran CSS Module user, or if you’re moving existing code to use Vite. If you are less experienced with CSS Modules and/or are working on new code then you probably think CSS Modules is limited, and continue on.

For some humor to the ending, I will not be using Webpack for Storybook 7 because it will error with “out of memory” and debugging that would be worse than this issue in Vite… 😅

I’ve implemented a fix via https://github.com/privatenumber/vite-css-modules (which is getting integrated into Vite core via https://github.com/vitejs/vite/pull/16018).

Testing and feedback will be appreciated!

I stumbled upon both these issues as soon as I implemented second route/page of the first app where I use these features. I am very surprised this issue isn’t reported way more often.

For posterity: the solution to ordering issue is to change architecture of your css modules to never overwrite css properties declared on the base class. You should only build upon base class with new/unique properties but never overwrite. For complex cases you will have a tree of classes where only leaf nodes are actually used as classNames for HTML elements (you will also have plenty of mixins). Of course this only applies if you compose from other files - in the context of one file you can do whatever you want.

It feels to me that this is just a trait of CSS Modules in their current form and can not be fixed. To depend on ordering of CSS declarations feels fragile and prone to being mishandled by post processing plugins.

I’m not particularly familiar with CSS Modules, but it works fine when you change their import order.

import originalStyles from './styles/original.module.css';
import smallStyles from './styles/small.module.css'; // import later for higher priority

In this small example it does have a workaround. But when I’m composing classes across many different css modules in my actual project, I have no way of controlling the import order myself. That’s entirely in vite territory.

I think this problem cannot be solved with Vite due to the architecture. Vite processes each css import individually.

• original.module.css will include .originalText
• small.module.css will include .originalText and .smallText

To dedupe .originalText, it will need to process all css files at once because it needs to know depency graph.

One way it may solve this is to rewrite composes into a import with JS. But I feel this is no longer “CSSModules”.