Exporter Anatomy

You can think about exporters as NPM packages - they are self-contained packages of code and configuration that gives them a very specific purpose. For example, when you find exporter package tagged as Flutter and Tokens, you can immediately say you will get styling code to be used in your Flutter codebase. When developing exporters, you have a complete control over everything defined inside exporters and how they should generate the resulting code.

Basic Exporter Package Structure

Each exporter package contains few required parts, and then whatever custom parts you want. Let's look at the Flutter exporter Supernova team prepared for you (you can get it right from Exporter Store):

Full structure of Supernova Flutter Exporter. Seems easy, right? It definitely is.

Let's go through all its parts, one by one.

(required) Package Configuration - exporter.json

The main configuration file that always must lie in the root folder is named exporter.json. This contains metadata about the exporter package such as name, author or description that will show up in the exporter store or anywhere the exporter is used (for example, by your collagues).

The main configuration file also allows you to define folder where your blueprints live, if you want to use javascript, what version of Supernova engine to use and so on.

exporter.json is present in every package and its configuration. Most attributes are required.

(required) Output Configuration - output.json

Another file that you will be tweaking often is output.json. This file contains mapping of what files should be produced when exporter runs and how it maps to the code you have created.

output.json defines the structure of what blueprints will be invoked and where the results will be written

(optional) Blueprint Behavior Configuration - sources.json

When you need advanced or granular control over specific blueprints, you can use sources.json to tweak it. Most often, you will use default configuration for each file you are generating, so this is optional.

With source configuration, you can make exporters that have different purposes depending on what they target. For example, you can create an exporter that when used from the CI, will completely remove all comments from your source code - but if your teammates use the same exporter inside the documentation, it will present the code with extensive commentary.

(required) Source folder - by default /src

The main folder that houses all the source code for all the blueprints (and optional javascript helpers). Each blueprint that you create must be present in this folder, otherwise, it will be ignored. You can use any structure of sub-folders to properly split and organize your blueprints.

Source folder housing all your blueprints

Each blueprint ends with .pr extension (Pulsar language). Please note that each blueprint must have a unique name, even if it is in a different subfolder.

Pulsar language allows you to "inject" blueprints into other blueprints. By making all files unique, you always know what to reference and you never need to worry about which folder you are referencing.

(optional) JS helper file

Last, but certainly not least, exporters can use your javascript code if you need to do some more complex computation outside the coding templates. You can define an optional javascript file that will host all those computation helpers.

If you want to learn more about all possible configuration options in all mentioned files, go directly to exporter configuration. Otherwise, it is time to learn about the arguably most important part of the exporter package, the blueprints.