Publishing Your Module

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 request, topbar and notification) are modules that we've published from our Trigger.io project.

How to publish your module

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.

Choose which module version to publish

To publish a module version, go to the list of existing uploaded versions, then click the Publish button for one of the versions.

Choose a module version to publish

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.

Pending approval

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:

  • informative description and change log
  • useful documentation
  • no avoidable clashes with other modules (see dealing with clashes)

A module needs to be approved

After approval

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.

Licensing your module

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.

What happens when you unpublish a module

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.

How to include .h header files in iOS modules

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.