Trigger.io app developers can use modules in two modules: public or private.
If a module has not been published, it can only be used in apps that belong to the same Trigger.io project.
A published module, however, can be found and used by anyone creating a Trigger.io app. The native modules which we, the Trigger.io team, provide (such as
notification) are modules that we've published from our Trigger.io project.
You actually publish a module version, rather than a module. This means you can selectively open up access to particular versions of the module, while keeping some private - during internal testing, for example.
To publish a module version, go to the list of existing uploaded versions, then click the Publish button for one of the versions.
At this point, we confirm that you accept the 2-clause BSD license for this module version, and the module version goes into the "Pending approval" state.
While we roll out the ability to self-publish modules, we are including a manual approval step where we double check the module versions on their way to being published.
We are checking for things like:
Your module will now be visible in our public module gallery, updated public versions of your module will appear in the changelog, and users will be able to add, configure and use the module in their apps.
The source of your module must be available under the 2-clause BSD license shown before publishing a module version.
Your module can use libraries which are distributed under a different license; the code you write for the module itself must be open-source under the BSD license.
Unpublishing modules should be avoided where possible. A good reason to unpublish a module version is that there is a serious security issue with that version. For general problems uploading a new version and setting it to current should be enough, new users will get the current version by default, and users of the old version will be prompted to update.
Unpublishing a module version will prevent new builds that include that module. However, if the user has already included that version in a build they will be able to continue rebuilding that particular config to allow them to push updates using Reload.
When publishing a module that you intend other modules to use as a dependency, it can be useful to include header files. To that end, any files you place in the
module/ios/headers folder in your module will be included in the header search path for modules that depend on it.