Our Selenium tests rely on a specific naming of class names in the HTML. E.g. class="Header__link", where Header is the name of a component, and link is a class in the component's CSS module).
With the current experimental CSS support in Next.js, there's no apparent way to customize the outputted CSS identifiers.
With next-css, we used to simply override the Webpack config with our own css-loader options localIdentName and getLocalIdent).
Please allow to override the Webpack config like it was the case with next-css.
Thanks!
Related to #8626.
How do you guarantee uniqueness throughout your whole application?
Our support should already be emitting class names like this, plus a hash ([fileName]_[exportName]__[hash]).
Can you trim off the hash from the end β this would be the best way to fix this?
In our case the file name is always styles.module.css. Itβs the parent directory that corresponds to the component name.
The component name (or rather its path) guarantees uniqueness. Another example of our former identifiers: signup_FacebookButton__icon. The CSS is in components/signup/FacebookButton/styles.module.css.
tl;dr: To set expectations, we're probably not going to ship with this ability by default. Read on for testing alternatives.
Customizing the emitted CSS identifiers is a footgun, as uniqueness is no longer guaranteed and we may optimize them in the future.
For example, we may explore these optimizations:
Our new CSS support is extremely focused on correctness β allowing this option may undermine that correctness and our flexibility to innovate in the future.
We can reconsider this when it's released stable if there's significant demand. IMO, there's better options here:
identity-obj-proxy to get stable class names. The emitted class name is an implementation detail that shouldn't be tested.getComputedStyle() β not class names.Thanks for the reply. I think your reasoning and strategy makes total sense. Also less configuration for the user.
I guess we'll have to use next-css until it stops working or and rewrite all the tests in the meanwhile. However, if there is demand after all, I suggest people interested in this feature to upvote the issue.
Cheers π
Your use case would probably be served well by identity-obj-proxy β but yes, you can keep using @zeit/next-css; we're not going to maintain it but we're not going to intentionally break or block it either. π
tl;dr: To set expectations, we're probably not going to ship with this ability by default. Read on for testing alternatives.
@Timer when you say not ship with the ability to do this, are you referring to what has been requested in this issue, or the ability to turn on the experimental CSS features (which would Customize the CSS identifiers)?
I'm using BEM and next-css and well... this is a big change, I'm using a well documented system for creating components (BEM), and I'm concerned that the new CSS features are going to mean that we'll end up having to re-invent the wheel by creating something that works with a CSS module based approach.
The ability to change the ident structure would be useful, as it would enable me to possibly get around changing the file structure:

I could maybe do this: [exportName]__[hash] for more uniqueness, or if forced, do this: [exportName] to allow me to carry on doing what I'm currently doing, but then you'd wonder why the ident name would be better as an option to turn off/on to allow some flexibility?
Most helpful comment
tl;dr: To set expectations, we're probably not going to ship with this ability by default. Read on for testing alternatives.
Customizing the emitted CSS identifiers is a footgun, as uniqueness is no longer guaranteed and we may optimize them in the future.
For example, we may explore these optimizations:
Our new CSS support is extremely focused on correctness β allowing this option may undermine that correctness and our flexibility to innovate in the future.
We can reconsider this when it's released stable if there's significant demand. IMO, there's better options here:
identity-obj-proxyto get stable class names. The emitted class name is an implementation detail that shouldn't be tested.getComputedStyle()β not class names.