Combine multiple design files into one library

Sounds interesting to have the option to collect/group multiple libraries.

Hi @Adam.Page! A couple suggestions come to mind with your case:

1. 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.

2. 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:

1. “Consumer File”: Insert the test component from “Test Library” (Wrapper contains Test Component).
2. Detach the Wrapper component, and you end with “Test Component”.
3. Update (& republish) “Test Component”
4. 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”.
5. 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!

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.