RFC: CSS extraction

[itsdouges]

Main point is to do a pass over their own components + node modules dependencies that are using compiled components and then to extract them to a single, atomic, css sheet.

This would need to be a bundler plugin. Webpack & Parcel.

The idea:

• You have a component library, let's call it @catlaskit
• You have a product, let's call it Gira
• Product Gira uses compiled components from @catlaskit
• Product Gira also defines its own compiled components
• We'd write this plugin to parse ALL compiled components (from both @catlaskit and Gira, and really anywhere) so when Gira builds their bundle - it extracts ALL compiled components to a CSS file
• We would want to build it in such a way so if there were cases it would report failures but not fail the build.

Cool right?

[itsdouges]

I've been doing a spike around the creation of a webpack plugin. Current thoughts:

• Writing a webpack plugin is harder than I would have liked
• We can't re-use the AST from the initial Babel run, unfortunately
• We need to do the file transformation with a webpack loader
• For simplicity and potential for extension later - we will create a plugin that then patches our extract loader in
• The loader should be ran after the initial babel run
• MVP of the plugin will not support HMR or anything of the like - with the assumption that the plugin only runs in PROD
• By default it should target every JS file - with config to constrain it to specific packages/files via the usual glob/regex approach common in webpack loaders

[cometkim]

@Madou would this be an option?

It would be nice to have additional options. However, there may be users who don't want the default behavior to change.

[itsdouges]

what option are we talking about?

[cometkim]

I'm wondering if it'll be necessary to extract CSS using the bundler plugin

Or can users keep using this library without the css extraction?.

---

Context:

I know extracted CSS works more efficiently in the browser, but in some cases is not, such as code--splitting and streaming. (And I think this is one of the main reasons Atomic CSS become necessary)

However, most of "(Near) Zero-runtime" CSS libs supports only pre-extracted ones but it has less advantages in React apps.

[itsdouges]

ah okay

you can keep using the library without CSS extraction 👍 - my advice is if you're publishing a design system or component library to NPM - don't extract to CSS yet

in an app that is consuming the design system, or component library, or even just writing their own components - turn on the CSS extraction so you get great performance gains, but still having the same developer experience and behaviour you're used to when writing CSS-in-JS

it is purely an additive thing however - again completely optional.

[cloudkite]

Excited about this library, nice work 🎉

In terms of code-splitting and SSR, will this support exporting to multiple CSS files that get loaded alongside their relevant async js chunk? I'm thinking about scenarios like nextjs.

[itsdouges]

Hi @cloudkite,

Currently it's planned to only extract to a single, atomic CSS file, with a critical CSS api available for initial SSR. The need for CSS chunks might not be needed - but it's something we're open to evaluate down the track 😄.

[itsdouges]

Current spike #561 and good discussion here #575