Enable CSS Module Support

[clintandrewhall]

There have been a number of discussions/requests for CSS Module support in Kibana. This would require an addition to the Webpack config, (perhaps more).

One use case would be #42545... see this comment for more information.

I know that EUI is considering moving to CSS Modules... perhaps someone from that team can weigh in on pros/cons/considerations.

[elasticmachine]

Pinging @elastic/kibana-operations

[elasticmachine]

Pinging @elastic/kibana-platform

[elasticmachine]

Pinging @elastic/kibana-design

[jfsiii]

I'm working on a new plugin (x-pack/legacy/plugins/integrations_manager in feature-integrations-manager branch) and would love to use CSS Modules there.

I'll wait for EUI to share their thoughts, but we used them on what's now Twitter Lite and the latest Web interface and they were great.

[snide]

We are indeed likely moving over to CSS Modules (via astroturf). @thompsongl will be sending out an email to dev with the details fairly soon. But yes, our plan is to convert EUI to use it (for prefixing and modularization), and then utilize it down in Kibana.

A lot of our original reasoning is covered in elastic/eui#1656, but again Greg will follow up with more detail on why we're leaning towards Astroturf.

[thompsongl]

Email went out yesterday, so I guess it's real now 😄

Getting CSS Modules enabled in Kibana as an option for plugin developers would be helpful for our cause.

EUI Perspective
Part of the appeal of CSS Modules is that it allows for incremental migration without also needing to fully rewrite EUI's base Sass mixins and functions. That migration will still take a good deal of time, and as a result Kibana will have to be able to accept CSS blob and CSS Modules coexisting, at least temporarily. This doesn't necessarily mean webpack or babel changes, but it should be on the radar.

Broader Perspective
The design team would like to become more standardized across the board in how app teams generate their style code. It's all about being able to provide better tools, documentation, onboarding, and support. As EUI moves towards CSS Modules, the best dev/desinger experience (in our opinion) will be for app teams to do the same and get the most out of our work.

astroturf
At this point knowing about astroturf is not of great importance (although folks might find it intriguing). A standard CSS Modules pipeline is just fine and would provide a very minimal, clear upgrade path. The EUI PoC sees just a difference in css-loader, which may not even be a requirement.

[clintandrewhall]

I love CSS Modules, and this would solve a lot of problems with scoping and obfuscating classnames in elements. Do we have any ideas when we could get this into x-pack?

[clintandrewhall]

Something to consider: I've had no success using postcss-prefix-selector with CSS Modules. It stands to reason there may be other postcss processors that would become difficult or disabled. Have you had any issues with this, @thompsongl ?

[thompsongl]

Not something I've seen (not that I've really spent time looking), but EUI's postcss process is also very small (autoprefixer, basically). This are good things to bring up as we start to investigate this

[tylersmalley]

This is being done as part of #53532

[tylersmalley]

This should be strait-forward to add to new platform plugins using @kbn/optimizer. Do we have a plugin which is looking to use this which we could introduce it for?

[tylersmalley]

The decision was to use Emotion, and not CSS modules. Closing this issue. Feel free to re-open if you feel like this needs discussed more.