Write a lint rule against CSS modules about create-react-app

[geelen]

I actually suggest a different approach — removing :local from css-loader altogether. I've started a discussion (webpack-contrib/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 :local is actually just a series of PostCSS transforms compiling to ICSS. And so the concept of import 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.css were 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.

[KyleAMathews]

In Gatsby we added CSS Modules support only for css files with names *.module.css per @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.

[gaearon]

At a later point, we sure can. For now let's keep it as simple as possible.

[giuseppeg]

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 🙏

[gaearon]

We can reconsider this in a few months. But it's good to warn until/unless we commit to supporting them.

[mxstbr]

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!

[casesandberg]

I got this 🐈

[hzoo]

@casesandberg I would use astexplorer to check the ast of the 2 forms

[casesandberg]

@gaearon Should this be in a eslint-plugin-create-react-app module or just as a rule in config/rules?

[gaearon]

I'm not sure how to structure rules in eslint so whatever is simpler ;-)

[casesandberg]

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.

[jaredpalmer]

@gaearon is the plan to write linters against Aphrodite and Radium too? Or is CSS-in-JS okay to use?

[jaredpalmer]

@mxstbr just wanted to doublecheck

[gaearon]

Meh, probably not worth it.

[thien-do]

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 :local by this way:

import styles from '!style!css?modules!./background.css';

is this something "no configuration and explicit behaviour" (an alternative to the .module.css approach)?

[outdooricon]

Yes, CSS Modules now exposes locally by default and globally by explicit declaration (:global)

[gaearon]

today I saw one of my teammate use CSS Modules in CRA without :local by this way

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]

@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)