sandhose
commented
2 weeks ago I think the best would be for us to not bundle, but only to compile each file with tsc.
There are two missing pieces with this approach:
- how we deal with SVGs
- how we deal with CSS modules
The former is somewhat straight forward: we could run svgr in the compound-design-tokens repository so that we export react components for each icon. This would have the immediate benefit of deduplicating icons used both in compound-web and in downstream projects.
The latter is a bit more complicated. There really isn't a simple solution that would work out of the box. What we could do is:
- use postcss to compile each CSS module file individually
- use
postcss-modulesto write class mappings - instead of writing JSON, we should generate JS to the dist directory
- when we compile TS files, we would rewrite CSS modules imports to use the generated JS file
- we would add a CSS entrypoint which imports all modules. That way, downstream packages can either import a single CSS file for all of compound, or only the individual CSS files they need
One big open questions is whether we still need a dual-CJS/ESM export? Would we be fine with only an ESM output? MAS would certainly work with it, but not necessarily Element Web/matrix-react-sdk
Currently, rendering a single
<Button>from compound-web pulls approximately 350Kb of JS and 160Kb of CSS. This is because we ship compound as a single bundled file, which isn't marked as side-effect-free, which means that bundler can't tree-shake out unused code and unused@radix-uidependencies.This isn't necessarily a problem for Element Web as it consumes almost all of compound, but it adds unnecessary bloat to smaller projects like MAS.