FEATURE: CSS build refactor (make react-ui-components easy to use)

[mhsdesign]

solves #3213
solves #3330

Puhh im happy to finally present you this pr.
I have been working on this concept since we started the esbuild pr but now everything just fell in place and ive got a fully working* improved css build and react-ui-components build.

*I currently cant find any style shifts in a side to side comparison :D

I took my previous refactoring at #3358 even further, now with a better written cssModules plugin https://github.com/neos/neos-ui/blob/aa9f5497678225b8b9414b247f97042aaa165447/cssModules.js and an actual consumer (dev) friendly build of the @neos-project/react-ui-components

What I did

• reduce the build speed by a third!!! esbuild + postcss + sass = 1500ms -> now esbuild + lightningcss = 500ms!!!
• replace sass @extends with css-modules composes https://github.com/css-modules/css-modules#composition
  • less code duplication in the css bundle 82.8kb vs 116.1kb :D
• replace post-css-modules with lightningcss (in Rust by parcel) as it offers an api that makes composes from "./file.css" usable as esbuild plugin: see: https://github.com/neos/neos-ui/blob/aa9f5497678225b8b9414b247f97042aaa165447/cssModules.js
  • the post-css-modules plugin offers no fully working way to build an integration with things like esbuild. The api is so cruel and unusable. In the webpack build it only worked by using a huge pile of shit - so im really happy that lightningcss offers a so simple api.
• Our.reset css modules compose mixin now uses the :where() selector, to force a low specificity at all time (just in case somehow the reset class lands at the bottom at the stylesheet, where it would have a higher specificity otherwise, which was our problem in the first place so we used sass. But after investigating if found out that since using my esbuild plugin the css class is as wanted at the top so it would be fine either way for now) edit i reverted to not using :where as we dont need it atm
• figure out to create a prepack build script for the react-ui-components
  • source maps
  • full build css (applied cssmodules, nesting and cssvariables)
  • typescript declarations
  • able to import only certain components
  • api surface should not change
• rewrote the css at some places to make it work with lightningcss
  • css grid template areas are hashed now and local to each css module, so we use composes from to use the template area in another css module: CSS modules option changes grid template area names parcel-bundler/lightningcss#144 (comment)
  • use function syntax instead of :global pseudo class: https://lightningcss.dev/css-modules.html#unsupported-features
• make the build-essentials obsolete (the css variables reside now in top level as css file)
  • infact the package is now only used by the webpack extensibility package
  • moved css var declaration from packages/build-essentials/src/styles/styleConstants.js to cssVariables.css
    • the file cssVariables.js creates a plugin for lightningcss which embeddes the css variables as usual
• renamed packages/react-ui-components/src/index.js to a typescript file so we have types when using import {Button} from "index.js"

Todos

• TASK: Script: Rename all import style from "./style.css" to style.module.css #3217 (after this one ;))
• remove any leftover .scss references like in linting
• investigate and fix now occurring minor style issues in the neos ui
  • maybe we need to revert some css styling changes again that happened due to the sass setup in 8.2 (i checked all ocurred css changes but none of them need to be reverted)
• test the neos ui
• figure out what to do with our legacy packages/build-essentials/src/styles/styleConstants.js -> it is currently used by the neos-ui-extensibility plugin build ... by accident?
  • the question is, whether its a usecase to use the neos ui css vars in a custom plugin (which currently seems to work)
  • also do we need the css vars in the backend modules anymore?: https://github.com/neos/neos-development-collection/blob/2790d168ab2bfd9ef0056e7c24a8e3c6d8e20169/Neos.Neos/Resources/Private/Styles/_CSSVariables.scss#L44
• selectBox.js import {isNil} from '@neos-project/utils-helpers';: due to isNil beeing in @neos-project/utils-helpers and this package not beeing on npm we cant properly use the react-ui-components as declaring it a dependecy alone would solve it. Regression from BUGFIX: Allow zero as value in selectbox #3069. use value == null;
• add comment for why value == null
• extract css grid declaration in another better named css file
• https://github.com/mhsdesign/esbuild-composes-from-css-modules
  • create an option for nesting and dont make it the default
  • only import composes dependency once per file
  • inline it instead
• react-ui-component rewrite readme
• react-ui-extensibility docs + demo (eg. how to get the font noto sans to work)
• currently backendmodules like https://github.com/Flowpack/media-ui use the lib-esm build of the react-ui compoents and might use runtime css variables defined for each backend module: https://github.com/neos/neos-development-collection/blob/2790d168ab2bfd9ef0056e7c24a8e3c6d8e20169/Neos.Neos/Resources/Private/Styles/_CSSVariables.scss#L44 is there a problem when the lib-esm build comes now with hardcoded values? I dont think so...
• rename lib-esm to dist and dont publish src files to npm ;)
• clean up compileWithCssVariables
• revert to [name]-[hash] css classes (for easier selecting in e2e (or place data-testid) )
• what if the media ui would use the new react-ui-components too? it would style crash as the css module names have the same names ... this is always problematic when two react-ui-components builds will be present ... -> solution modify prefix for react-ui-components
• check date picker
• Bug: react-ui-components FontAwesomeIcon externally nearly unusable #3378
• react-ui-components do we need to allow direct imports eg @neos-project/react-ui-components/dist/Button/index.js or even unthemend? @neos-project/react-ui-components/dist/Button/button.js
• cleanup ts configs
• Check on BUGFIX: Fix dropdown spacings for reset button #3282
• Check on BUG: Publish Dropdown has a large distance to the right #3330
• Assert no extensions are used when importing

How I did it

blood. sweat. tears.

How to verify it

use the lib-esm build in the ui ^^

react-ui-components build

see if it works correctly, as you have used before (by linking the package locally or some other hack)

or create a js and html file like:

import React from "react"; 
import ReactDom from "react-dom";
import {Headline, Button, Label, IconButton} from "./lib-esm/index"

ReactDom.render(
    <div style={{background: "#2b2b2b"}}>
        <Headline type="h3">Hello</Headline>
        <Button>Click</Button>
        <Label>Hi</Label>
        <IconButton icon="neos">Hello</IconButton>
    </div>,
    document.getElementById("app"),
)

build it with yarn esbuild test.jsx --outdir=dist --bundle and view the html in the browser.

Upgrade instructions for Neos Ui components @neos-project/react-ui-components:

With this change the CSS build stack of the Neos Ui was modernized, due to this it became possible to make the package react-ui-components easier to use: Developers requiring the npm package will no longer need to worry about the required CSS preprocessing from the sources (lowering nesting and applying css-modules). A prepack script will build the css to native css and also take care of css modules. This means that for consumption of the components you will only need a simple bundler to load the vanilla css - nothing else. It is advised to read the new readme before updating so you can identify any other changes.

[mhsdesign]

Is now completely ready for review ;)

See https://github.com/neos/neos-ui/blob/d8ab716a5753a00bec648cfd480bd0aa3e347abc/packages/react-ui-components/README.md for a new documentation of the react-ui-components ;)

[markusguenther]

Looks good to me, if we have bugs left, we need to fix them anyways.