Proposal: CSS plugin and infrastructure improvements

[jquense]

Hey Folks 👋

I'd like to write out a few ideas and proposals for modernizing and future proofing the CSS infrastructure.

Issues

1. css-loader in Gatsby is old, and rarely updated. That's expected since it's built into Gatsby core and limited in the major versions it can bump on css-loader to Gatsby's own major bumps

2. Extending CSS handling is hard, gatsby-plugin-postcss has to fully find and replace the Gatsby loader, because otherwise the css files will will be handled by both, it makes it difficult to adjust the behavior or integrate other tools that use .css files.

3. Postcss support is awkwardly handled by gatsby-plugin-postcss, since it replaces the css-loader, you lose autoprefixing based on Gatsby's understand of browser support as well as any Gatsby specific configuration that is required for css (e.g. excludes and includes of internal files)

Proposals

To address 1 I think we should add gatsby-plugin-css outside of core, so that other plugins can be built off of it, and core can consume it, giving users the option to update it independently as they like. (I've already done this partly)

To address 2 I would suggest that Gatsby support postcss via a postcss-config.js file out of the box, removing the need for gatsby-plugin-postcss and exposing utilities for plugins like sass and less to consume to easily create new gatsby plugins on top of the base one, maintaining all the nice postcss utility functionality like autoprefixing and giving plugins the option to additionally support postcss plugins as well (via a postcss.config.js or plugin options). This would unify the feature sets of all the preprocessor plugins nicely

For 3, I think that the core css loader used to handle .css files needs to provide an API for safely extending the files that it handles or does not handle. As an illustration, using astroturf I may want the Gatsby plugin to fully ignore generated astroturf.css files, at the moment there isn't any good way to do that. I'm proposing adding some amount of additional action/function to the api call for onCreateWebpackConfig that allows adding new excludes, includes, or tests to the default webpack rule.

If ya'll think this is a good idea i'll put together a suite of PR's

[jquense]

any feedback?

[KyleAMathews]

These proposals make a lot of sense to me. Thanks for the proposal writeup and offer to implement. Would love to hear what others think e.g. @wardpeet & @DSchau

Main question is how breaking would this be? We're planning a Gatsby v3 soon which this could fit into but some e.g. (2) could be implemented in v2 as well?

[jquense]

This can all be implemented with a non-breaking deprecation ramp. Plugins would require major bumps but that's low cost. For gatsby core the thought would be to do it like the react-next plugin. Core stays the same for v2, but gatsby-plugin-css is added and when used, replaces the built-in css handling.

point 3 is a bit orthogonal and does need some API crafting, but I think it should be a purely additive change. TBH the challenge here is allowing gatsby to provide a good exp out of the box but let plugins adjust or update independently.

• if CSS plugin is built in, then exclude/include utils need to be exposed to tweak the loader tests.
• Unfortunately that makes it harder to have a plugin replace the css logic, and still have those utils work.

The most flexible approach might be to have a first class gatsby-node API for doing this in the same babel include or ignore options can be configured

[wardpeet]

@jquense I'm making some leeway on this. Sorry for the late response, but this has been on my mind for a while. gatsby-plugin-css made sense to me, but it's difficult to pull it off with the loaders.css() architecture that we have. Gatsby is going to improve the cadence of major updates, so these issues will become less of an issue.

My proposal:
We'll keep gatsby-plugin-postcss, gatsby-plugin-sass, gatsby-plugin-less as is but they will always use the latest and greatest loaders. They will override the default CSS rules with their own.

In Gatsby Core, we'll enable postcss config files like we do babel

We should provide helpers to find and overwrite rules inside onCreateWebpackConfig to do these things yourself. (I still need to flush this out).

How does that sound?

[jquense]

They will override the default CSS rules with their own.

how would that work? The concern when plugins need to mutate the base config this way is that it's really hard to combine plugin that do that together consistently.

I'm not sure that having gatsby use a postcss config automatically is a good idea, it would need to be very clearly scoped to only .css files otherwise you'd accidentally apply a bunch of postcss rules to sass or less files unintentionally. This still though doesn't address cases where the user wants to treat subsets of css files differently, e.g. .linaria.css or .astroturf.css files.

Sorry if this is inarticulate, i've very quickly put a response together!