next.js css-modules styles omitted from resulting class names

[vschoettke]

Hi @Mistereo,

when using the built-in css-modules from next.js together with next-linaria the css-modules classnames are stripped away from the final html. (e.g. import styles from "../styles/some.module.css and then use it like className={styles.someClassname}) This was working ok with version 0.10.

Affected Version: 0.11 and 1.0.1-beta

I tracked the problem down to the rules that were added in 0.11 specifically rule.options.modules.exportOnlyLocals = false seems to be the problem.

[jantimon]

I have the very same problem - why do we need exportsOnlyLocals for linaria?

[joyfulelement]

Encourntered the same issue with v0.11.10. Will encounter runtime error like below:

Warning: Prop `className` did not match. Server: "null" Client: "class_name__9KLlt"
    at div
    at div
    at div
    at div
    at div
    at section
    at render (webpack-internal:///./node_modules/@linaria/react/esm/styled.js:47:13)
    at section
    at render (webpack-internal:///./node_modules/@linaria/react/esm/styled.js:47:13)
    at section
    at render (webpack-internal:///./node_modules/@linaria/react/esm/styled.js:47:13)
    at footer
    at render (webpack-internal:///./node_modules/@linaria/react/esm/styled.js:47:13)

This is a major road block for adopting linaria with Nest.js when built-in css-modules is broken. It's almost a year since the case has opened, are there any thought about how this can be resolved any time soon? Thanks

[scowalt]

+1. As a workaround, I have a local version of next-linaria that has rule.options.modules.exportOnlyLocals = false; commented out.

This line was added with #5. I wonder if its inclusion is even strictly necessary to fix the bug. If it is, maybe withLinaria could support a configuration that disables this change? If it isn't necessary, perhaps it could just be removed