I wanted to bring this up for discussion as I use camelCase by default with CSS modules since it lets me key in the class associations a bit faster.
/* CSS */
.my-class {
}
.my-other-class {
}
With:
// css-loader?modules&camelCase
import Cn from 'classnames'
import css from './MyComponent.module.css'
...
css.myClass
Cn(css.myClass, css.myOtherClass)
Without:
// css-loader?modules
import Cn from 'classnames'
import css from './MyComponent.module.css'
...
css['my-class']
Cn(css['my-class'], css['my-other-class'])
This may just be an opinion piece; but for me, it looks cleaner and can be typed faster.
Yeah this makes a lot of sense. Actually I thought CSS Modules did camelCase by default :-)
I'll support this change. Anyone else with thoughts? @gatsbyjs/gatsby-core-maintainers
This would be a breaking change so wouldn't go in for a bit.
Why don't you just define your css classes as .camelCase ?
This will make it harder for everyone to lookup for references...
CSS Modules doesn't enforce it, though it is recommended that you write your classnames in camelCase specifically because of this case.
though I'm not sure if I agree with mutating the class names like that.
If i write .my-class in CSS, but want myClass in JS, why not just type .myClass in CSS in the first place?
I have no excuse... Other than dasherized class/property names have been the standard with CSS for years and old habits die hard, I suppose. ๐
FYI, css-loader injects both versions of css.myClass and css['my-class'] into the resulting object when camelCase is enabled, so this actually wouldn't be a breaking change.
e.g.
// css =
{
"my-class": "gobbledygook",
myClass: "gobbledygook",
}
Well if it's not a breaking change... I can't see the harm then.
Ah, well, as long as it doesn't get rid of my-class, but instead appends a myClass then yeah, I'm for it.
:+1:
Same thoughts, adding this option seems reasonable. I didn't know about ๐
@tribou still want to add a PR?
I know gatsby uses Flow. But some more notes for potential restriction on css module names (if you use TypeScript) https://github.com/Quramy/typed-css-modules#remarks
I have to agree with the comments. Just start writing in camel case. If you're referencing in camel case when it's actually kebab, it's not exactly clear what you're referencing. I agree it takes a bit of getting used to, but it doesn't seem reasonable to add such functionality for the sake of old naming conventions.
It appears there's too much opposition on this one. Unless we get some more positive comments, I'll close this for now.
adding a comment in support, we do have this option set for all our projects and I don't think anyone has ever been confused. case transformation accross languages is fairly common concept for programmers I think, especially js ones who often work with backends in other not node. I for one also refuse to write css classes in camelCase, I just can't bring myself to so that :P
Yeah, I think this is quite reasonable to add. If someone would like to create a PR I'd be happy to merge it.
Just want to point out that there is automatic conversion from kebab-case to camelCase other places in DOM land:
data-my-attr= โ dataset.myAttr)background-color: โ style.backgroundColor)There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications we're clearing out old issues as many of them have already been resolved with the latest updates.
See a more recent update on this issue with #5458 ๐
Most helpful comment
I have no excuse... Other than dasherized class/property names have been the standard with CSS for years and old habits die hard, I suppose. ๐
FYI,
css-loaderinjects both versions ofcss.myClassandcss['my-class']into the resulting object whencamelCaseis enabled, so this actually wouldn't be a breaking change.e.g.