When a Penpot file has many available Shared Libraries, each library currently has to be connected individually using the + action in the Libraries modal.
This becomes repetitive when working with larger design systems split across many library files, especially after importing .penpot files from external design systems.
Proposed enhancement
Add a bulk action in the Shared Libraries section to connect all currently available libraries at once.
The existing per-library + action would remain unchanged.
Example:
Connect All
UX questions
I’d like guidance from the Penpot team on:
- whether the action should be called Connect All or Add All
- whether an active search/filter should affect all available libraries or only the visible filtered set
- how partial failures should be handled
Contribution
I’m interested in implementing this enhancement myself as a community contribution if the approach fits Penpot’s UX and product direction.
If approved, could a maintainer create or link the corresponding GitHub issue for tracking?
Image: Screenshot of the Add to Library screen for reference.
This is a really interesting idea for a contribution!
Though I do have a workaround for anyone who finds themselves wanting to connect the same libraries to a file every time: create a Default libraries file.
- Create a new file called Default libraries (or whatever you want)
- Connect all your regularly-used libraries to this file
- Publish this file as a library
- Every time you create a new file, you just need to connect the Default libraries file, and you’ll get access to all the libraries connected to that file.
The benefit of this is that you could also create different collections of libraries for different contexts, rather than an all or one-by-one approach.
2 Likes
I’m curious why you decided to keep your design system spread across so many files, especially if you intend to add all these files to most new project.
I realize we’re only seeing a very small segment of you design system in your screenshot. But there it seems each component resides in it’s own Penpot file.
2 Likes
Thanks Laura — the “Default libraries” approach makes sense for a set of libraries that are used regularly across multiple files.
The use case I had in mind is a little different. I’ve mainly run into this after importing larger design systems/component collections into Penpot, where the available libraries may already be split across multiple .penpot files. In that situation, connecting them one by one becomes repetitive.
So I was thinking of “Connect All” more as a bulk convenience for import/migration or occasional setup, rather than a replacement for the Default Libraries workflow.
If that still sounds useful from Penpot’s UX/product perspective, I’d be happy to explore implementing it as a contribution.
1 Like
Good question. The screenshot probably makes the structure look more intentional than it actually is.
My main use case comes from importing existing design systems/components into Penpot, particularly .penpot files originating from external design resources. In those cases, the imported resources can end up distributed across many separate Penpot files/libraries, rather than being a design system I originally structured that way.
So I’m not necessarily proposing that splitting a design system into one file per component is the ideal workflow. The issue is more about situations where a user already has a larger collection of available libraries for example after migration/import — and wants to connect several or all of them without repeating the same action individually.
Laura’s Default Libraries approach also makes sense for libraries that are used regularly across projects. I was thinking of “Connect All” more as a convenience for importing/migration or occasional bulk-selection workflows rather than necessarily something users would do for every new project.
If this kind of workflow is uncommon or there’s a better Penpot-native way to structure imported design systems, I’d also be interested in understanding that before implementing anything.
