What's the strategy to distribute (and consume) a component library created with Pigment CSS? #116
Replies: 4 comments
-
I was wondering the same thing. |
Beta Was this translation helpful? Give feedback.
-
@oliviertassinari, I was rechecking this today as I'm still seeking answers. I suppose you had to find a solution for MUI? Could you share your findings? |
Beta Was this translation helpful? Give feedback.
-
I'm still looking for an official answer, but here are my two cents after reading the release note for MUI v6. You don't publish any CSS and instead ask the consumer to use Pigment CSS and leverage the I am still unsure about a solution for the case where we use Pigment internally, but I also want to publish it for people who don't use Pigment. At this stage, the best course of action seems to be a monolithic CSS file (with all the components' styles) generated at build time. |
Beta Was this translation helpful? Give feedback.
-
I am also interested in this topic. I'm able to build and consume my library following the steps in the Readme (specifically, the Within our enterprise, we support projects using a variety of frameworks/tooling, so if we can't get PigmentCSS to play nice, we may have to reconsider migrating. |
Beta Was this translation helpful? Give feedback.
-
Runtime CSS-in-JS solutions have a convenient "story" when bundling and distributing since the end user has very little to do, and only the used styles are inserted at any given time.
As I delve into Pigment CSS, I'm curious about the optimal way to ship styles generated with this tool. Should we generate one style sheet per component (if that's even possible?) or is a monolithic stylesheet more efficient? And how should the consumer link the stylesheet? I'm sure you have insights into this at MUI, given your extensive experience developing a fully stylised component library.
To be honest, this question applies to any Zero-runtime CSS in the JS library.
Beta Was this translation helpful? Give feedback.
All reactions