Let's discuss how Supernova and exporters work.
Supernova's mission is to convert designs into production-ready code. To achieve this, Supernova translates any design input (be it a screen, color, font, component or any other piece of design information) into a universal data model describing it.
Import of that information is usually not 1:1 but smartly optimized, emulating how a developer would do it manually. Examples of such optimizations are removing layers that bear no information, merging layers, fixing names, filling empty or nonsensical names, and so on. Supernova also adds extra metadata such as relations between elements, and can infer layout information and many other useful bits that can be used when exporting production code.
Once input is processed, it is immediately available to the exporter.
The diagram above describes how Supernova internally works. No matter the design tool, data is always converted into a universal data model, allowing you to prepare export procedures once and use them for all platforms - not caring at all about where the information comes from. It also shields you from changes to platforms, such as Sketch changing its data model, Figma changing its API, and similar issues all-too-common when developing any such system.
Lastly, the universal data model contains extra information obtained through optimizations, and also that provided by users - such as navigation connections, animations, etc.
Exporters are packages containing all the necessary information to translate the universal data model of Supernova into production-ready code. Its output can be as simple as a few lines of CSS styles - however it can export truly complex stuff, such as entire Swift, Flutter, or HTML-based projects or even an entire website, down to the last asset. An exporter in its simplest form works like this:
Once the user (or CI) runs the export, the exporter package is run against Supernova's universal data model and produces output files, which are written into the destination - file system, GitHub, or any other.
In the model above, you can see export as a single entity that magically makes everything happen. But export is a rather complex procedure that can be completely customized. There is a good reason for this level of customization - just imagine how different an iOS project is from a Web React project.
The following diagram represents the full run of one exporter:
Step by step, the exporter produces data like this:
The exporter package is loaded and validated. The exporter package contains the full configuration of the export (including metadata such as its description, name, how the exporter should behave) and most importantly the blueprints and mapping files that participate in the content creation.
Each exporter package contains an exporter.json file containing this configuration, from which blueprints and mapping files are referenced.
Blueprints are "templates" that describe how the code output should be generated for one specific file and contain any code needed to obtain the data for the template. Blueprints can access Supernova's data model through the use of pre-defined functions.
Mapping files then define the relationship between one blueprint and one concrete item that will be produced when running this export. For example, if we want to generate a README.md file, we'd create a blueprint containing content of the README.md file and then one mapping entry, specifying where the output of the blueprint should be written to (such as root/README.md)
When all definitions are loaded, the exporter runs.
The exporter runs by taking all mapping files and executing their commands. For example, a mapping file can ask the exporter to execute a specific blueprint and then write it to a file system. However, it can ask the exporter to do many other operations - such as to generate .png assets, generate vector assets, copy bundled resources, and so on.
Once all mapping files are exported, the output is written to a filesystem in the directory that was selected by the user before the export runs.
Export is finished.
Now that we've seen how exporters run, let's look at how to access the universal data model of Supernova, so you can start using the design data in the exporters you'll build and use.