What are Penpot’s plans for a Plugin System?

The main goal for it is to facilitate the developers to create and publish their own custom plugins that integrate with our platform.

Here are ours first ideas on how this system could work:

The difference between a plugin and a code contribution is that their code for the plugins will be separate from the core app. Another advantage is that these plugins could be made by using HTML, CSS, and JS.

To ensure that the plugins are safe and high quality, we will have a “devs area” where developers can test and refine their plugins before publishing them to the marketplace. This safe zone will allow developers to experiment and try out their ideas without the risk of disrupting the platform for other users. Also, to insure quality, plugins will have a review system.

The user will have in their profile settings a “plugins” section from where they will be able to activate or deactivate the chosen plugins.

One step in that direction is our recent release, where we launch the new webhook. Webhooks are this little, cool ‘broadcast’ technology that allows other tools to listen to Penpot’s team and design activity and (automatically) perform actions of their own.

We would love to hear your opinion. What are your thoughts about this new feature?

We can’t wait to see what developers will create and how they will improve their experience on our platform with this new way of collaboration. To keep the progress of this feature, you can follow here: Taiga

14 Likes

Reading the Taiga ticket I wonder what “Plugin types: we don’t want to set restrictions so far” means – since for the plugins to not interfere with the main UI (or do other problematic stuff) you will most likely need some restrictions in place, most likely, and following architectures like web extensions in browsers, an internal API for the plugin interacting with the content/svg and some for hooking into specific points in the UI.

1 Like

Interesting, I’m glad you started working on this feature.

One of the things I find useful as a developer is accessing code for the design item that’s selected. But I usually use a niche UI technology and not css directly.

I have created a Zeplin extension that outputs code as Imba code. But it wasn’t easy to build. One idea would be to expose a helper function that the extension author would implement. It takes a list of css props and the block type (div, span …) and outputs a string representing the code in the target technology.

This is probably an over simplification, but the idea is to provide building blocks for common use cases.

P.S: for syntax highlighting, GitHub - shikijs/shiki: A beautiful Syntax Highlighter. is a great tool that’s lightweight, active and rich

1 Like

I feel excited about your idea of a plugin-system and would love to do some contributions without the need to learn ClojureScript :slight_smile:

  1. Out-of-the-box support for TypeScript is a critical feature to me. When working in an unknown environment, TS supports developers to get an overview of methods, objects and data-store APIs. The initial set-up of a TS-library surely requires some time and may not cover all aspects of the application from the very beginning, but it saves you guys on the long-term a lot of documentation work!
  2. The ability of easily re-using existing components and CSS classes would be lovely. Ideally, a new plugin should not ship its own CSS, but implement the given Penpot styleguide to avoid UI duplicates and inconsistencies. I do not want to recommend you to go all-in with React components or styled components to achieve this, but some sort of re-usability pattern for public styles and components would be great.
  3. Lastly, I am always happy about example-plugins and pre-configured plugin skeletons which developers only need to fork/checkout to get started, without dealing too much with bundling processes or coding styles. There could also be some kind of one-click solution connected to Gitpod, so that I do not need a fully setup Penpot environment on my device to develop and test a small plugin.
4 Likes

I’m really excited about Penpot and better API support, so much that I already started working on a project using the current API documentation.

I’m hoping that the API would implement OpenAPI spec or something similar, so generating API boilerplate would be easy to do for a lot of programming languages.

There is a more detailed community post about this topic, that I wrote here and as a feature request

2 Likes

Hello fellow Penpot enthusiasts. This is a very intriguing topic and discussion. While I am not yet very savvy in this space yet, I started reading the API documentation and made my first plans about how to implement webhooks into my own workflow. I would love to have a plugin for VS Code to interact with my Penpot designs and projects, so that I can import code into a Next.js or TypeScript project. The idea would be, to use the components from Penpot directly in my code. No clue if I ever will be able to achieve this, but it would be nice to have the visual design in Penpot and then using it directly in the development environment.

1 Like

Let’s leverage the existing success stories of tools like Sketch and Figma to fast-track developer adoption. The Sketch and Figma APIs are robust and intriguing. Exploring avenues like React-SketchApp (GitHub - airbnb/react-sketchapp: render React components to Sketch ⚛️💎) and Figma Scripter (GitHub - rsms/scripter: The Scripter Figma plugin) can be instrumental in extending the benefits of Penpot to your developer community.

1 Like

Yeah, Given the direction Penpot has taken with SVG as first-class objects in design, I shall use the plug-in system to bring new attributes in the SVG objects that will bring excellent engineering breakthroughs in multi-discipline interactions- that too without disturbing the Clojure environment.

1 Like