Repository navigation
Write a lint rule against CSS modules #98
Description
As much as we appreciate the pain points CSS Modules are solving, we’ve made a decision not to use them in this project. You can see some discussion on this in #90.
However Webpack currently lets you use custom :local syntax to “enable” them in regular CSS files. We don’t want people to do this because this limits our ability to add more CSS tools or migrate from Webpack to other bundlers in the future.
This is why we should enforce that people don’t use :local syntax. Otherwise we’ll just randomly break their apps when we change something in how we handle CSS. This won’t be fun, and people will blame us for that even though we explicitly do not support this feature.
Luckily, it is easy to fix. We should write a custom lint rule with ERROR level that is triggered on a statement like this:
import styles from './styles.css';This, however, should work fine:
import './styles.css';This semi-enforces that you don’t use CSS Modules because we just don’t support them. We can ensure your CSS stays reasonably portable in case we want to change the underlying architecture.
Reference on writing ESLint rules: http://eslint.org/docs/developer-guide/working-with-rules.
If you want to work on this, please write here so we don’t have multiple people doing it at the same time.
Activity
casesandberg commentedon Jul 22, 2016
I got this 🐈
KyleAMathews commentedon Jul 22, 2016
In Gatsby we added CSS Modules support only for css files with names
*.module.cssper @andreypopp's suggestion which seems safe enough. I don't have good enough pulse on where CSS Modules are in adoption life cycle but this might be a good compromise as CSS Modules are one of the most useful things to come along in the CSS world in a long time.hzoo commentedon Jul 22, 2016
@casesandberg I would use astexplorer to check the ast of the 2 forms
gaearon commentedon Jul 22, 2016
We can reconsider this in a few months. But it's good to warn until/unless we commit to supporting them.
casesandberg commentedon Jul 22, 2016
@gaearon Should this be in a
eslint-plugin-create-react-appmodule or just as a rule inconfig/rules?gaearon commentedon Jul 22, 2016
I'm not sure how to structure rules in eslint so whatever is simpler ;-)
casesandberg commentedon Jul 22, 2016
I'm not really sure either-- if there is a possibility we will have more of these in the future we should probably bundle them all together in one plugin.
gaearon commentedon Jul 22, 2016
At a later point, we sure can. For now let's keep it as simple as possible.
jaredpalmer commentedon Jul 22, 2016
@gaearon is the plan to write linters against Aphrodite and Radium too? Or is CSS-in-JS okay to use?
mxstbr commentedon Jul 23, 2016
Both Aphrodite and Radium are fine, since they don't use any webpack-specific features, which is what we want to avoid.
If we ever switch away from webpack and people are using CSS modules they won't have any chance to update because it won't work!
giuseppeg commentedon Jul 23, 2016
CSJS is a good alternative to CSS Modules although I like the fact that you are not trying to enforce any CSS [in JS] methodology 🙏
geelen commentedon Jul 27, 2016
I actually suggest a different approach — removing
:localfromcss-loaderaltogether. I've started a discussion (webpack/css-loader#308) over there but I don't expect it to be resolved fast enough for the needs of this project, so I think this linting rule is a good solution in the interim.Interestingly, the whole concept of importing something from a CSS file is what I was hoping to achieve by proposing ICSS as a standard format — a minimal extension of CSS that allowed passing symbols around. This is what css-loader actually supports, everything related to
:localis actually just a series of PostCSS transforms compiling to ICSS. And so the concept ofimport styles from "./styles.css"was always intended to be more widely-applicable — not specific to Webpack, CSS Modules, or anything. It just turned out to only be really used by CSS Modules.So I'd love to think that any future bundler of CSS would permit some form of exporting from CSS to JS and so this kind of syntax will become more standard, but I admit that's well and truly beyond the scope of this issue :)
For what it's worth, if this project did decide to "support" CSS Modules, I think the best way would be if all files ending in
*.module.csswere loaded with CSS Modules like Gatsby does — I think that's the closest thing we could get to having both no configuration and totally explicit behaviour. But I get that it's not on the roadmap for the moment.jaredpalmer commentedon Jul 27, 2016
@mxstbr just wanted to doublecheck
gaearon commentedon Sep 3, 2016
Meh, probably not worth it.
thien-do commentedon Sep 20, 2016
Hi, I don't know if anyone care about this anymore, but today I saw one of my teammate use CSS Modules in CRA without
:localby this way:is this something "no configuration and explicit behaviour" (an alternative to the
.module.cssapproach)?outdooricon commentedon Sep 20, 2016
Yes, CSS Modules now exposes locally by default and globally by explicit declaration (
:global)gaearon commentedon Sep 24, 2016
Please tell them it is entirely unsupported and we reserve the right to break this in any release.
We don’t officially support Webpack loader syntax in import statements. If you can't find something in CRA docs then it's not supported.
jfmengels commentedon Oct 14, 2016
@gaearon There is an eslint-plugin-import rule forbidding Webpack syntax in the path (it basically warns if there is a
!in the path).I have noticed you disabled the whole plugin because of its compatibility with eslint-loader, but you could probably still use rules like these, that do not attempt to load/read other files. (I'm happy to make you a list of rules that should be fine and useful if you want)