Using the VS Code Extension
Now that you have found the exporter you want to use through the Exporter Store and installed it to make it available for everyone in your workspace, you can start generating production code with it.
This guide covers running exporters in VS Code, which is the recommended way of using exporters. If you can't use VS Code for some reason, please skip to using Exporters with Cloud.
Configuring the source design system
In order to properly export production code, the exporter package needs to know what design system you are targeting. The VS Code extension makes this dead simple - start by clicking on Select design system in the top left corner:
You will be asked which workspace you want to use. If you just started using Supernova, you are very likely a member of just one workspace, so select that one. Next, select the design system:
Note that design systems will be listed only for the workspace that you have selected. Lastly, you need to select a version of the design system you want to use:
You will see a list of versions that you have created, plus a special option called Shared draft. The shared draft means you will always get the latest changes, as they are added to the design system. Think of it like version control "head." This is a great option if you are developing and your designers are making a lot of changes to the design system that haven't stabilized as a new version just yet. There is always at least one version in each design system, the Shared draft.
Running an exporter
When you select the workspace, design system, and version, the interface of the Supernova panel will change accordingly. You will also see the list of exporters that you have installed for that workspace, that you can now use.
Hover over the exporter you want to use, and select the Run Installed Exporter option. This will download the appropriate design system data, generate the code and give you the option to save the result to any folder on your file system. Select the folder you want your code to be stored in and it will be written immediately.
Write rules
The exporter produces code in a completely deterministic fashion - each exporter exactly defines how the code output should be structured, relative to the root of the export provided by the user, or in the case of an automation pipeline, through the configuration file. In the case above, you have selected the root of the export manually, so the files are written to that specific folder.
The exporter result overrides local files that have the same name / path as those that are generated, but will not touch other files! It will however create sub-directories inside the root folder if they are missing and defined within the exporter package.
This allows you to mirror the exact structure of your codebase when you get to customizing the exporter packages. Note that the folder you are exporting to doesn't have to be empty and the generated files can co-exist with other ones located next to them.
Of course, manually selecting the export destination every time something changes would be pretty tedious, so there is a much better option - configuring the default project exporter.
Last updated
