Nicer css module generated names

[modernserf]

You may not even realize this, but your current config supports css modules, it just doesn't use them by default -- i.e. you can use :local in CSS files and it will generate class names, it just doesn't make all class selectors local by default.

I'm totally fine with global being the default scope for now (much less confusing for beginners) and adding the :local pseudo-class where I need it, but it would be nice if more human-readable classes were generated. Use something like:

style!css?localIdentName=[path][name]---[local]---[hash:base64:5]!postcss

as the loader config in webpack.

[gaearon]

Can you please explain this on an example? We don’t “officially” support advanced features but they indeed may work by accident 😄 . I don’t know enough about CSS modules to understand what you’re saying, but we’d rather not make them easier to use because we want to be sure that everybody has the same setup. Otherwise can’t just release updates that switch to another CSS solution, for example.

[mxstbr]

True, very good catch @modernserf! I'm +1 for this change.

@gaearon css-loader supports the :local wrapper for class names to create localized classes. (i.e. css modules by effort)

// This is now usable like if it was CSS modules! 
:local(.button) {

} 

We didn't specify how it should generate those classes, so they're quite ugly and unreadable – what @modernserf is suggesting is making them more readable.

[corbanbrook]

Simply using [local]---[hash:base64:5] is nice solution. This will output classnames like button---2VzVQ. Including the path and filename is a tad excessive imo and just makes it difficult to grok when scanning over the outputted markup.

[gaearon]

I don’t think we want to support this. I would actually like to turn this feature off.

The reason is we might want to migrate away from webpack in the future. We’d need to make our CSS files are as vanilla CSS as possible (aside from minor stuff like relative dependency paths).

I would accept a PR that forbids extra features if possible.

[gaearon]

(Btw I totally understand the benefits of local scoping. We just don’t think it’s a good default for people learning React, and it’s way too custom syntax that is incompatible with many other tools. We’d rather move into direction of encouraging CSS in JS for better encapsulation.)

[mxstbr]

I think it's not possible to turn off local scope by default (ref webpack-contrib/css-loader#193), but we can simply set the generated name to whatever the name is anyway. Give me 5 minutes to try that.

[modernserf]

I regret bringing this to your attention.

[gaearon]

@modernserf I understand your frustration but it’s still better than if we change the bundler in a few months and all your styles would break. Having to back out of infrastructure changes (e.g. super fast new bundler) because people relied on webpack in ways like this would be super sad.

[mxstbr]

I kind of agree with @modernserf though, this is a nice escape hatch for people to explicitly use CSS modules without needing to eject. It's not like we document or encourage this anywhere…

[gaearon]

People will use it whether we document it or not, and then “create-react-app broke my app” will become the next javascript f*****e.

[gaearon]

A semver-compatible patch update can literally break people’s builds because of it.

[mxstbr]

I still haven't found a way to disable it properly, it'll break peoples builds either way.

[gaearon]

We can add a custom loader that throws on non-standard syntax.