Write a lint rule against CSS modules

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 https://github.com/facebookincubator/create-react-app/issues/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.

[geelen]

I actually suggest a different approach — removing :local from css-loader altogether. I’ve started a discussion (https://github.com/webpack/css-loader/issues/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.