[DataGrid] Agnostic styling

[romgrk]

Part of the design-system agnostic work.

New styling solution.

Summary

This PR implements the datagrid styling solution as a new babel plugin that transpiles css() calls to static CSS classnames. The styles are extracted to a separate stylesheet for production mode. In dev mode, the css() calls are injected at runtime. @mui/x-internals/css contains shared logic that is used by the production and development codepaths.

To ensure that classes ordering stays consistent across prod & dev modes, the babel plugin builds an import graph to determine in which order the dev mode css() calls would be evaluated (and we can assume those are always at init time, because we only support static styles). In practice, this means styles defined in leaf imports will be defined after styles in non-leaf imports.

We are abusing a bit the babel build process, as babel plugins are meant to transform one file at a time, not to create new files. We attach a nodejs beforeExit handler to write our final CSS stylesheet. It's not very clean, but it avoids the need to mess further with the build process.

Code transformation examples

For an overview of what is supported, see the test cases: index.test.js

We only support static styles, except for vars.x.y.z, for which we do a bit of hardcoding/magic in order to make it work (the alternative would be manually writing var(--DataGrid-t-x-y-z).

Changes

I've only included the implementation of the babel plugin here, except for GridColumnHeaderTitle which I've used as an example of what would change for the rest of the codebase. I could complete the styling changes as a separate PR to facilitate the review, or as part of this one to ensure everything works before merging.

[mui-bot]

Deploy preview: https://deploy-preview-16677--material-ui-x.netlify.app/

Generated by 🚫 dangerJS against 43d7008

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[romgrk]

The workflow I proposed should allow to build production docs using the aliases

That's not a good thing though, the aliases mean we build the docs (which is basically the only place where most of us dogfood our products) through a substantially different setup than what end-users use. Now that I've been trying to get rid of the aliases, I was able to notice a few ESM issues that we might not have caught before release otherwise. I also remember some perf benchmarks giving different results when built inside our docs (in a playground page) versus in a newly setup project using the NPM modules.

The aliases are fine for dev mode to get HMR, but prod mode should not use them.

A babel plugin that reaches outside of its abstraction level. This is debt because it breaks the natural assumptions we have about our babel setup and thus facilitates introduction of regressions.

I don't like it either but it's going to stay as it is for now considering our timeline. Using something other than babel would mean introducing a new build tool in our build pipeline, and I don't want to investigate that.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.