If Supernova would be a human, the exporter package would be its brain. The package tells it how to behave when code generation runs down to the latest detail. And as its brain, it has access to all tools available. This means that exporter package can do any operation and can access any data Supernova provides. If you see it in the user interface, you can use it inside the exporter. And you can also use more information that is not normally exposed at all.
But the brain analogy is not exactly true. That is because, usually, you can't change the brain inside one body (but it would be cool!). In Supernova, however, the brain simply connects to its body. Do you want to generate code for a different platform? Simply switch the brain - change to different exporter package - and the resulting code will be dramatically different. Do you want to generate just assets? There is a brain for that.
The exporter package is loaded just before it is used and then discarded immediately afterward. That means that you can freely change its configuration and it will always run the latest version. The full execution flow of exporter package is as follows:
Exporter package is loaded and validated
Validation checks that exporter contains valid exporter.json configuration
Validation checks that all blueprints have proper configuration files
Validation checks that all blueprints are valid
Blueprints are compiled and validated to see that they don't have a syntax error
Mapping information is loaded. Mapping contains "commands" to be executed in parallel, such as "invoke a blueprint X", "generate .png asset" and so on. Mapping also contains an information about where to write the output once it was generated
Any static assets provided with package are loaded into memory
Exporter runs all loaded commands. This means generating blueprints, generating assets, and so on. The entire output of the export is kept in memory at this point
If all commands were successful, the export output is copied to the destination. It is only possible to write into the local file system now
As a general note, the exporter paralellizes everything and uses it can to achieve better performance, so running export on a multi-core CPU is much faster than without it.
Exporter package is a folder that is of specific structure so MacOS can recognize it as a bundle. If you open the exporter on windows, it will be just a directory and nothing else, but you can still edit it because the format is fully open, readable, and accessible. Exporter package always comes with an extension
snexporter. The proper bundle structure is as follows:
flutter.snexporter/Contents/info.plist // Bundle info file, needed for OSX to recognize the bundleSupernova/exporter.json // Main exporter configuration fileicon.png // Optional package iconBlueprints/ // Folder containing blueprint definitionsblueprint1.blazarblueprint2.blazar...Config/ // Folder containing blueprint configurationsblueprint1.jsonblueprint2.json...Assets/ // Folder containing all static assets to be copiedassets-1.txtasset-2.zip...
You can find details about each of the part of the exporter and their purpose in the following sections:
Configuration section teaches you about basic metadata and base configuration file
Blueprints section teaches you about how blueprints are stored and their configuration files
Mapping section teaches you about how mappings are stored and their configuration
User interface teaches you about how to adjust the user interface to obtain additional information before the export runs (Coming soon)
Bundled assets section teaches you about how to bundle assets with exporter package, so you can then copy them on export (Coming soon)