Packages: Move build config to calypso-build package

[ockham]

First steps. See p9oQ9f-87-p2 for context. Somewhat similar to WordPress/gutenberg#13814 -- ideally we'll converge at some point.

Jetpack counterpart PR: Automattic/jetpack#11344

Changes proposed in this Pull Request

TODO:

• Make work for JP
• Separate package for style assets?
• Use for Calypso itself
• ...

Tasks we'll need to do to follow through with this

• Our (S)CSS buildchain. Depends on stuff in assets/stylesheets/_shared, which I'm currently directly including. Wondering if that should be its own package that the calypso-builder package can depend on. Est: 3d
  • To make things more fun, this is run through node-sass during build (and our files subsequently depend on the resulting public/custom-properties.css). If we turn this into an npm, this would need to be part of the published package.
  • We could maybe drop the SASS compilation on this one and just turn it into CSS? It's mostly just custom properties definitions after all.
• Need to parametrize root dir in webpack config (instead of hard-wired __dirname). Est: .5d
• References to Calypso's config. E.g. used for env, project name,... Hopefully avoidable or parametrizable. Est: 1d
• Factor out a lot of Calypso specific config that doesn't carry over, e.g. server (section) loaders. Est: 2d
• 'Actual' code from Calypso (that we'd need to publish as npms -- regardless of which build tool we end up using in JP). Not a lot to see here:
  • components/jetpack-logo
  • lib/format-currency/currencies
  • lib/route/path
  • lib/simple-payments/constants
  • lib/simple-payments/utils
• Est: .5d if we copy/duplicate, 3d if we package
• Stuff relevant for client/extensions. Is any of that even still used? Can we yank it out altogether? (This is probably minor/optional)

Testing instructions

See Automattic/jetpack#11344

/cc @Automattic/team-calypso @Automattic/gutenpack

[matticbot]

Test live: https://calypso.live/?branch=try/calypso-build-package

[jsnajdr]

I like the idea to publish the SCSS build scripts and configs as a standalone package. The common SCSS definitions (mixins, functions, variables) can live there. Also the PostCSS and webpack loader configs.

The custom-properties.css built file can be shipped as part of the published package. We now build it as part of the webpack workflow, but that could be moved to a NPM script? install, postinstall, build, prepublish, prepare -- whichever is the right one 😆

We could maybe drop the SASS compilation on this one and just turn it into CSS? It's mostly just custom properties definitions after all.

The sources use a lot of SASS variables (all the $muriel-* ones) and functions (hex-to-rgb). I don't see a straightforward way to convert them to CSS. Shipping the CSS as part of the published NPM package is a more viable option.

[simison]

Depends on stuff in assets/stylesheets/_shared, which I'm currently directly including.

Might be good to have a closer look at what we're actually depending on in blocks and if changing some Calypso variables/mixins to core equivalents makes more sense?

[ockham]

Depends on stuff in assets/stylesheets/_shared, which I'm currently directly including.

Might be good to have a closer look at what we're actually depending on in blocks and if changing some Calypso variables/mixins to core equivalents makes more sense?

Yep -- but in terms of moving forward, I'd play the transitivity card again: IIUC, a lot of these are based on a8c-color-studio, so it's unlikely that we can easily phase out our style basics altogether soon. We can however start depending on Gutenberg stuff and remove redundant definitions from ours.

[ockham]

Thanks @jsnajdr , makes sense and confirms what I had vaguely in mind!

The sources use a lot of SASS variables (all the $muriel-* ones) and functions (hex-to-rgb). I don't see a straightforward way to convert them to CSS. Shipping the CSS as part of the published NPM package is a more viable option.

Not immediately relevant, but maybe it'd be possible to propagate some changes upstream (to color-studio)? I.e. have them change their SASS vars to CSS custom properties? (Not sure about the functions.)

[jsnajdr]

Not immediately relevant, but maybe it'd be possible to propagate some changes upstream (to color-studio)? I.e. have them change their SASS vars to CSS custom properties?

That could work: the color-studio package already exports the color data in several forms: JSON, SASS variable definitions, CSS classes. Adding a new color-css-variables.css file with definitions like

--color-muriel-purple-0: #f7f5f8;

should be fairly easy.

The question is whether the postcss-custom-properties plugin will work with that. Needs to be tested.

[ockham]

Seems like it has been brought up in that repo's issue tracker even: Automattic/color-studio#3

[blowery]

There are some other big bits that currently use SASS that are hard to replace with custom props:

• The z-index map (this makes my head hurt, though ideally components wouldn't have to mess with z-index at all?)
• media queries (ditto)

[ockham]

Closing. This has served its purpose to inform pafL3P-kB-p2 and https://github.com/orgs/Automattic/projects/80.