Add ability to change camelCase option for CSS modules
See original GitHub issue(I think this is a feature request - it may just be a bug, or a small cry for help 😉)
Is your feature request related to a problem? Please describe. Hi there - I’m building a storybook and Gatsby front end for thegymnasium.com. Our goal is to use storybook to prototype new UI enhancements which will get promoted into a gatsby front end once they’re tested and ready for production.
I’m currently running into a configuration issue with Storybook and CSS Modules. What I would like is to be able to use camelCase
in our JavaScript code to reference style names for CSS classes imported via CSS module. That configuration option looks like it lives within the webpack css-loader.
By default, it seems that Storybook’s CSS module config only produces class names that are hyphen-separated
. Our team would prefer to use camelCase here, which means setting the camelCase
option to either true
or only
, from what I can tell.
Describe the solution you’d like
I’ve been digging through docs on how to correctly customize the webpack config for storybook to both use CSS modules and provide that camelcase option, but I haven’t been able to get it right yet. I’m under the impression that what I need to do is something like this, but I think I also need to modify the css-loader
in that config. I could use some help there.
Describe alternatives you’ve considered
An alternative for us would be to use only skewer-case
css class names, however for the sake of code legibility, we’d prefer to use class names like:
<div className={classes.myCssClass} />
as opposed to
<div className={classes['my-css-class']} />
Are you able to assist bring the feature to reality? Yes, I think I can - but I’m not sure where to start in order to find the base config to use for css modules and css-loader that storybook uses by default.
Additional context
This problem came to my attention because I’ve been developing our new react components side-by-side in storybook and Gatsby. Obviously, the goal is for them to be rendered exactly the same in both environments. Because we rely on camelCase css classNames from within our javaScript code, any classes defined by a .hyphenated-class-name
in CSS do not work in Storybook. This is a side-by-side shot of our footer component running the same code in Gatsby and Storybook:
If I console.log
the css class names being generated by the css modules in both gatsby and storybook, I see the following:
gatsby generated class names
storybook generated class names
You can see that gatsby generates both hyphenated and camelCase class names, and storybook only does the former.
I should also add that I commented about this in a recent PR on the gatsby repo - in the screenshot there, you can see that the problem I’ve highlighted above is still present.
Reproducing
If you’d like to reproduce this issue, you can:
- pull down our repo for the combined gatsby and storybook front end here: https://github.com/gymnasium/gym-front-end
- run
yarn install
- run
yarn storydev
, which will start both storybook and gatsby together. You can inspect class names in the footer to see that some are missing in the storybook version.
I hope that’s enough information to be clear about what I’m going for here. Thanks!
Issue Analytics
- State:
- Created 4 years ago
- Comments:10 (2 by maintainers)
Top GitHub Comments
Sorry for the late reply, You can tweak the config by creating a
webpack.config.js
in the storybook folder.To determine what to change, you can run storybook with the
--debug-webpack
flag. That will print the full webpack config for you, so you know what to edit.Note that storybook 5 requires your webpack.config.js to export a function, not an object.
I think your modification to the config would be something like:
config.module.rules.find()
find the correct rule to make the modification onverify the changes are correctly applied by running storybook with
--debug-webpack
again.Hi everyone! Seems like there hasn’t been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don’t have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks!