Keep design system data in tight sync with production codebases
The main purpose of the developer side of Supernova is to keep the design system data in tight sync with the production codebases. This is a daunting task when done manually — not only must the process be well-documented and each change highlighted, but also the changes must be applied to existing projects by skilled developers.
Supernova takes a different approach — full automation of design system data delivery, either manually through the VS Code plugin, or automatically through our automated Design Continuous Delivery pipeline. And it can do that for any platform or tech stack you run, with very little effort. All thanks to exporters, the core technology powering the Supernova developer platform.
Exporters take design system data from a single design system that you or your team work with, and transform them into production code using blueprints, sophisticated templates powered by our own templating language we call Pulsar. Each exporter package is unique, and they differ in what platform, technology or stack they target and what code they produce.
You can think of exporters like NPM packages — each package has a specific purpose and they are relied upon to produce deterministic results — e.g., a computation, generation of an image, etc.
Now, we hear you: you built a new programming language that I have to learn?! Don't worry — Pulsar is actually very similar to other templating languages you already know and love, such as Handlebars or Mustache. We just greatly improved upon them and added some sweet capabilities you know from other programming languages, and added some specifics that make obtaining design system data and generating code for any platform a breeze - all the bits you usually have to cobble together and maintain yourself when trying to automate design delivery to code.
Exporter package store
Supernova is all about saving time and automating tedious processes — so building an exporter package before you can get any production code out of your design system would go against that. In many cases though, fortunately, codebases are built with recommended guidelines in mind — be it the style of the code, the structure or even things like project architecture.
So instead of building exporters yourself, you can rely on the exporters that were already built by the Supernova team (or the community) to do the work for you. Simply by going to the Supernova exporter store, you can browse existing packages and install them for your workspace. And if something doesn't fit you, you can even "fork" them and change everything about the exported code, down to the last character.
You are not limited in the number of exporters you can use! In fact, many projects in Supernova currently use more than one. The exporters can respond to events happening inside a design system, such as when a new version is published, and deliver the code to the codebase automatically. And you can hook multiple exporters at once to these events...
Exporting code to your codebase
You can export code in two ways — manually or automatically. The manual export can be invoked either on Supernova Cloud, or directly inside your VS Code IDE, using the Supernova developer extension.
The automatic code delivery can be configured on Supernova Cloud, but once configured, delivers the code on your behalf without user interaction.
When exporting the code, you will be asked to select which design system you want to code against, which version and also what installed exporter to use. You can have one or many exporters fo different purposes. Exporters are blazing fast, so you will always get your code nearly instantly — and it is up to you how you want to use the exporter code in your codebase.
You should now have a solid idea what exporter packages are and the scope of what you can do with Supernova, so it is time to dive into exporting your first code! Let's start with the obvious choice, exploring the Exporter Store.