calypso-build: remove dependency on calypso-color-schemes

[jsnajdr]

Removes the calypso-build dependency on calypso-color-schemes and lets projects that use both packages configure the needed CSS bits explicitly.

Fixes #36466.

• removes the calypso-color-schemes colors prelude from the default webpack config. That was useful when the colors were defined as SCSS variables, but now when they are defined as CSS variables included in the CSS output, the prelude no longer makes sense
• removes the default importFrom declaration from postcss-custom-properties default config and replaces that with configurable importCssCustomPropertiesFrom option for the SassConfig preset.
• updates Calypso webpack config to use the new importCssCustomPropertiesFrom option.

Let's see how this works with other projects that use calypso-build.

A little reminder about what postcss-custom-properties does: when there is a CSS rule that uses a CSS variable:

:root {
  --color: red;
}

h1 {
  color: var( --color );
}

it has one problem: it doesn't work in IE11 and other old browsers without CSS variable support. postcss-custom-properties adds a "polyfill" here. With preserve: false, it inlines the variable:

h1 {
  color: red;
}

With preserve: true, it preserves the CSS variable and adds a fallback definition:

h1 {
  color: red;
  color: var( --color );
}

Browser with CSS variable support uses the version with a variable (that can be overridden with a different value, depending on active CSS classes), IE11 uses the fallback.

importFrom option specified a module where to import the CSS variables from. When compiling modularized CSS with webpack, the CSS variable definitions are in a different compilation unit (the entrypoint) and the compiled CSS doesn't see them. They only come together after webpack bundles all the pieces together.

[matticbot]

Test live: https://calypso.live/?branch=remove/color-schemes-from-calypso-build

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[jsnajdr]

Rebased, resolved conflicts and fixed a little bug that caused several builds to fail (destructuring and option from an undefined options parameter).

[ockham]

• removes the default importFrom declaration from postcss-custom-properties default config and replaces that with configurable importCssCustomPropertiesFrom option for the SassConfig preset.

I'm a bit worried about this change, specifically about its implications for calypso-build consumers. Just to re-iterate calypso-build's intended nature, it's supposed to work pretty much out-of-the-box with a number of sane defaults (some a bit specific to WP and/or Calypso related projects), and to allow incremental customization for advanced usage -- e.g. add your own babel config, add your own webpack config, etc; the point being that it's not our own obscure abstraction layer/config language on top of those tools, but we're just allowing users to configure these tools directly.

Requiring users to add a webpack config and to use the SASS preset with a custom option to inject calypso-color-schemes there seems a tad too complex for something I'd expect to be a rather recurring pattern in A8c projects (at least the ones that are going to use Calypso componentry -- and that might be more and more, going forward).

It was me who coded the Webpack presets concept in their current shape, but I'm not particularly proud of it, and I don't think it's a great API to expose for less-advanced users (while it might be okay for Calypso's own Webpack config, which is just a different level of complexity) -- to some extent, it is "our own obscure abstraction layer/config language".

This is a recurring problem with the intended 'zero-but-incremental' (Peano? 😄 ) config system in a world where different small pieces need to be configured, and there is no homogenous standard for all of them (Babel presets are pretty much the nicest thing we have). I think I'd still prefer something that's closer to postcss' own config system.

All that goes to say: Can we modify calypso-build to respect a project's custom postcss config if there is one (and ditch the SASS preset based postcss config), in a similar way as we do for Babel?

[simison]

calypso-build's intended nature, it's supposed to work pretty much out-of-the-box with a number of sane defaults (some a bit specific to WP and/or Calypso related projects)

That's a fine and I agree with the sentiment but a bunch of CSS color variables, many specific only to Calypso (think --sidebar-background) that always end up in the build doesn't feel like a sane default.

Sanity check fails especially when trying to update calypso-build at consumer's end and breaking a bunch of stuff when calypso-color-schemes or color-studio have changed. It's quite painful to hunt down those changes 3 levels down the dependency chain. It's especially painful because missing CSS variables don't fail loudly; they just don't work and you can find out only by manually testing everything and cross-checking CSS variables.

Moreover, there can be projects that should use a completely different set of colors (think e.g. Happy tools). Shipping colors by default is a blocker for such adoption.

The solution is to either not include the color variables and let consumers keep up with a specific version of color-studio/calypso-color-schemes, or make it opt-in (or even opt-out).

Thoughts?

[simison]

could postcss-custom-properties plugin be left out if importCssCustomPropertiesFrom is falsey? That would effectively make this opt-in.

[jsnajdr]

@simison postcss-custom-properties is useful even in the default configuration when neither of the "preserve" and "import from" options are passed. It then converts:

:root {
  --color: red;
}

h1 {
  color: var( --color );
}

to

:root {
  --color: red;
}

h1 {
  color: red;
  color: var( --color );
}

It inlines the default variable as a fallback. Think of it as a IE11 polyfill.

The "import from" option is needed only when the variables are defined in a different stylesheet. node-sass and postcss process stylesheets one by one, exactly as they are stored in sources. Only at the very end does webpack merge them together.

[ockham]

All that goes to say: Can we modify calypso-build to respect a project's custom postcss config if there is one (and ditch the SASS preset based postcss config), in a similar way as we do for Babel?

I think I might've found the missing piece: https://github.com/postcss/postcss-loader#path

We should be able to do something similar to

wp-calypso/packages/calypso-build/webpack.config.js

Line 104 in 18ec5d5

configFile: babelConfig,

[ockham]

Implementation notes for #36471 (comment):

• Generalize this logic to work for any kind of config file:

  wp-calypso/packages/calypso-build/webpack.config.js

  Lines 63 to 71 in 18ec5d5

  	let babelConfig = path.join( process.cwd(), 'babel.config.js' );
  	let presets = [];
  	if ( ! fs.existsSync( babelConfig ) ) {
  	// Default to this package's Babel presets
  	presets = [
  	path.join( __dirname, 'babel', 'default' ),
  	env.WP && path.join( __dirname, 'babel', 'wordpress-element' ),
  	].filter( Boolean );
  	babelConfig = undefined;

• Use it to set the default to the postcss.config.js we ship with calypso-build, akin to

  wp-calypso/packages/calypso-build/webpack.config.js

  Line 104 in 18ec5d5

  configFile: babelConfig,

• Update calypso-build's README to add a section telling users how to use their own postcss.config.js. As an example, maybe show how to use a config that imports the color schemes prelude.

[ockham]

Going to take a stab at this now.

[ockham]

Going to take a stab at this now.

#37060

[jsnajdr]

Closing because @ockham did it much better in #37060.