search

css-modules / postcss-modules-values

Pass arbitrary constants between your module files
ISC License
38 stars 6 forks source link

Values as selectors clashing with existing selector names on 3.0.0 upgrade #4

Closed dannyshaw closed 5 years ago

dannyshaw commented 5 years ago

Moving from version 2.0.0 to 3.0.0 caused issues with clashes between imported colors, and local CSSModule selector names.

...
@value white from colors;

.white {
   color: white;
}

2.0.0 caused output:

<div class="white_h32kjh">

3.0.0 caused output

<div class="#ffffff">

I'm sure you're aware of this issue and perhaps why the version bump was major? I couldn't find any release notes warning of this potential breaking change so figured I'd create a note here for others who may be experiencing the same issue to find.

alexander-akait commented 5 years ago

It is expected, you can find notes about this here https://github.com/css-modules/postcss-modules-values/releases/tag/v3.0.0, before updating you can prefix all @value (for example @value v-white from colors;) and when do upgrade. Now @value can be used in selector.

dannyshaw commented 5 years ago

Thanks for the response.

I was looking specifically for breaking change warnings about the fact that this upgrade can and did break the project's styles.

We backed out of upgrading because it's just too big a task to go look through every css module file and look to see if there are clashes between values and class names in a very large code base. Potentially we could regex rename but it would be a loose replacement that would need to be hand-checked for every occurrence.

nwalters512 commented 3 years ago

@alexander-akait I just hit this when a the latest version got pulled into our dependency tree and spent half a day trying to track down why builds were suddenly failing. This change is really disappointing, especially since https://github.com/css-modules/postcss-modules-values/pull/2 didn't provide any rationale or justification for why this change was made. Is that rationale or any alternatives documented anywhere? Would you consider a PR reverting this change under a new major version, or at least allowing a config option to opt out of this behavior? Unfortunately it's not feasible for us to make the suggested change (rename with a prefix) across dozens of apps and thousands of files.