Open vschoettke opened 3 years ago
I have the very same problem - why do we need exportsOnlyLocals
for linaria?
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
+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
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 likeclassName={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.