Our team uses separate libraries to organize different aspects of our design system. Although our adopting designers must enable multiple libraries to take advantage of the whole design system, this separation has been beneficial for elements that can be logically grouped, such as icons, typography, colors, etc.
But when it comes to UI component designs, our attempt to carve out multiple libraries feels tortured and illogical. We were inspired by Esther Cheran’s demonstration of a single-file-per-component organization scheme, but decided against it since we don’t want to burden our adopting designers with the need to enable one library per component. So we’ve left all our components in a monolithic design file that continues to grow rapidly in size & complexity.
Currently, a library can only publish assets from a single design file. But is that restriction necessary? Would it be possible to further abstract the library concept, allowing one library to collect & publish assets from multiple design files? This would allow our design system contributors to create design files that are small, tidy, fast to load, easy to merge, etc., while still minimizing the number of libraries our adopters would need to enable in order to take advantage of the the whole design system.
Hi @Adam.Page! A couple suggestions come to mind with your case:
By leveraging default libraries (set by your Admin), consuming/adopting designers won’t have to worry about enabling libraries since the correct libraries will already be toggled on for them.
If you don’t want to go down the single-file-per-component path, you have the option to build inheritance between libraries as needed. Below is a basic diagram of how this might work for your case.
You can decide how you want to separate out your system internally first. You can then ‘bundle’ them in the ‘official’ single library that consumers use. Be mindful that this will require two publish actions: one from the internal library, and then again in the official library.
Hopefully these notes help your team consider the best option. Let me know what you think!
Thanks so much for these detailed suggestions, @Clara! #2 is very intriguing and sounds like it could be a great match for us.
The two-tiered publishing actually sounds like a benefit to me more than a burden , since it could allow us to finalize & test individual component releases without exposing them too broadly. Then we could queue up multiples of those for a clean, consolidated release to the rest of the organization.
We’ll play around with this on our side and I’ll drop you a line if we have any follow-up questions. Thanks again!
I’m not sure if this really solves the issue efficiently. I can only see that components brought in from another library needs to be embed in another component in order to be published. And every time you embed, you lose access to all of the top-level properties. However, I see a trend people asking for this feature, so hope it will be covered down the road.
@Clara I like the approach of having individual component files bundled into a bigger lib.
However, I was unable to do it as in your comment.
I created a “Test Component” file with one component, then a “Test Library” file referencing “Test Component”.
But that’s not enough. As @Matthew_Ortega mentions, to make “Test Component” visible, I need to wrap it with a new component in “Test Library” and export it again. It also means replicating any variants.
In this simple test, I ended with a very confusing situation:
“Consumer File”: Insert the test component from “Test Library” (Wrapper contains Test Component).
Detach the Wrapper component, and you end with “Test Component”.
Update (& republish) “Test Component”
Go back to “Consumer File”: Figma detects the changes and asks me if I want to update. But, “Test Component” is not in the “Assets” of “Consumer File”.
If I update “Test Library” to reflect the new changes, “Consumer File” will not see the modifications because it’s detached from “Wrapper”. I found this extremely confusing: because I get notifications from libraries that I don’t use directly, and it’s easy to mess up the update/publish order.
My conclusion from this quick test is that the approach of bundling individual libraries into a bigger one gets messy pretty quickly. At the moment, a single library file or multiple files (with default libraries) is the only viable option.
@Diego_Fernandez1, you’re correct, you’d need to wrap the component again as a new component. And the method would also require publishing twice.
Before step 4, you’d need to also publish “Test Library” again as well.
It’s a different kind of maintenance for the tradeoff. It’s not the method I would personally use, but I wanted to pose it as an option to explore in case folks find it worth the effort!
, since it could allow us to finalize & test individual component releases without exposing them too broadly. Then we could queue up multiples of those for a clean, consolidated release to the rest of the organization.