At this point, you should know how to pick and install an exporter that suits your needs, how to manually export the code, and how to set up the default exporter for your codebase so you can get production-ready code on demand, every time something changes.
But in many settings, the design system pipeline must be automated, usually with some combination of your CI/CD, possibly using Style Dictionary, and also tons of scripts and code to glue it all to work together.
Building and maintaining such a pipeline is a daunting task and will always result in a brittle solution, because the services that provide you the data (such as Figma API, Style Dictionary definitions, and so on..) evolve and change over time, and the potential for breaking is exponentially proportional to moving parts in your pipeline. Worse yet, when you change the underlying tech stack, you usually have to rework a major part of such pipeline.
With Supernova, you don't need to go through the pain of creating and maintaining such a complex system, because we have created a flexible, plug-and-play, end-to-end pipeline for you.
Supernova brings the very first Design Continuous Delivery system flexible enough to be "bent" to any situation or technological stack. At the highest level, it works like this:
This configuration is called hook. With the hook in place, the DCD will work fully automatically:
You are completely shielded from any complicated implementation — you only really care about what you do with the code that the system generates on your behalf.
Configuring hooks can be done by accessing Supernova Cloud > Code Integration > Hooks. To create a new hook, simply click on + NEW button to show the configuration dialog.
You must fill all properties except notify, which is optional (but highly recommended):
Currently, there are three types of events you can watch, with distinct purposes:
The exporter will run every time a new version of a design system is released.
With this setting, Supernova will run exporter every time anything changes in your design system, with a short buffer window so you don't get overwhelmed with the updates.
The exporter will run every time the source is updated and there is new data, for example, if a Figma file is published.
If you want to disable the hook, you must delete it using the appropriate option in the hook detail. Lastly, the hook can be updated at any moment just by reconfiguring their properties. Please note that any modification to the hook will be immediately applied and used on the next run.
The pipeline can work in two ways: With, and without notifying you about the result. When you don't want to consume the code right away and you want to just keep it available to your developers, then notify should be left empty. This will create a build for each run and will keep it securely stored on our servers until you want to access the code.
However, the more useful choice is to be notified that the code was generated and is ready to be used. In this case, you need to provide notify URL which will point to your API that will manage the incoming data.
With notify set, every time the exporter runs (either successfully or with potential error), we will invoke your API and send the following JSON payload through POST:
"name": "Example workspace"
"name": "Example Design System"
"name": "A version name",
"name": "Example exporter"
"name": "Example hook"
"message": "Finished exporting source colors.pr"
There are several important pieces to this payload:
You will get a complete set of the configuration attributes inside the payload, allowing you to precisely identify which event happened, in which design system, and forward the code wherever you want to.
Job describes the result of the run:
If the exporter created code successfully, urls will be provided as well. At this point, there will always be just one link, but we are reserving this option for more flexibility down the road.
The URL links to a secure, signed .zip file that can only be accessed with the URL provided in the payload, containing the structured output of the exporter.
We have made this system so you can consume the data in any form or shape you want — so it is completely possible to forward them to your build pipeline or for example commit to GitHub from your API without us not needing to have access to your repositories. This way, you are always in control.
That being said, we realize not everyone wants to handle the code delivery through their API, and in many cases, it would be possible to push to source control on your behalf. For this reason, we are actively building a way to automatically open pull requests within git repositories.
If you run a more complex tech stack with multiple platforms, or you have several design systems for different purposes, you can create an unlimited number of hooks with different combinations of exporters / design systems or even delivery URLs. For example, more complex stacks can configure hooks in the following fashion:
This way Android and iOS both move with stable versions from multiple design systems, however, documentation exporter that exports HTML preview of the available tokens runs immediately after the change, so designers always have the latest preview available to them.
We believe that with this system, you can get extremely creative and ultimately efficient. And to give you full control over how to export the data, the next part of this documentation will walk you through the creation and anatomy of the exporters, so you can build any export and code generation task you want if you have specific needs not available on the Exporter store.
This documentation was created using Supernova's fully customizable documentation engine.Start building your docs now!
© 2022 Supernova.io