To lowercase classnames in composes

[shoonia]

In new version of stylelint-config-standard@^20.0.0" has a rule value-keyword-case if use flag --fix then classnames fixed to lowercase in composes.

run:

npx stylelint src/**/*.css --fix

transform:

.btnDefault {
  font-size: 16px;
}

.btnPrimary {
-  composes: btnDefault;
+  composes: btndefault;
  color: green;
}

"stylelint": "^13.0.0",
"stylelint-config-css-modules": "^2.2.0",
"stylelint-config-standard": "^20.0.0",

Thanks!

[pascalduez]

Hi @shoonia,

so what's the question / issue then ?

Yes, I noticed this change as well. But I don't feel like it's a rule this preset should deal with.

[shoonia]

I think that composes is related for current config. Is it possible fixed in current config? Or we need use 19 version or fix it in locally?

[pascalduez]

I think the value-keyword-case rule is not only targeted at the composes property, but any property value that could potentially use a keyword with casing style. That's a style decision to be made per project and not as broad as a shared config like this one.

We could potentially add it scoped with ignoreProperties, but still feel like the wrong place.

Leaving this issue open though to gather further feedback.

[privatenumber]

I also expected that adding stylelint-config-css-modules would make the necessary changes to make my stylelint config to make it completely CSS Modules compatible.

I had to add the following override to my config:

'value-keyword-case': ['lower', {
	ignoreProperties: ['composes'],
}]

This is a pretty major issue (not just a stylistic one) because CSS Modules composes is case sensitive and the autofix breaks this code:

.RedButton {
  color: red;
}

.Button {
  composes: RedButton; // becomes "redbutton"
}

Ideally CSSModules supports quoting values to get around this, but doesn't seem like it: composes: "RedButton"

[zmeyc]

@privatenumber Just a couple of thoughts:

This problem is not only with composes, but with values as well.

@value pageBackgroundColor #14619b;

.page {
  background-color: pageBackgroundColor; /* becomes pagebackgroundcolor */
}

Possible workaround is to use variable-names-with-dashes for values and composable class names and only use camelCase for exported classes.

I.e.

.button-base {
  ...base button props...
}

.normalButton {
  composes: button-base;
}

.redButton {
  composes: button-base;
  color: red;
}

For consistency, dashed style can be used for exported classes as well, but it's less convenient to use from JavaScript side (className={styles.redButton} vs className={styles['red-button']}). Though not too bad, given than camelCase is untypical for css.

Possibly disabling value-keyword-case is better, but imo this shouldn't be done only for composes as it is a partial fix.

[privatenumber]

Forgot about that -- thanks for surfacing.

Yeah, I got around mine by converting values to kebab-case. And as you say, kebab-case in classnames are harder to use because of CSSModules creating a JS interface for the CSS.

Disabling value-keyword-case entirely could interfere with a codebase's stylistic enforcement so I wouldn't do that.

[pascalduez]

Made a test in #20.
As previously stated this solve only a small part of the casing issues. So I'm a bit wary to merge it.