Plugin development
To create a plugin for semantic-release
, you need to decide which parts of the release lifecycle are important to that plugin. For example, it is best to always have a verify
step because you may be receiving inputs from a user and want to make sure they exist. A plugin can abide by any of the following lifecycles:
verify
prepare
publish
success
fail
semantic-release
will require the plugin via node
and look through the required object for methods named like the lifecyles stated above. For example, if your plugin only had a verify
and success
step, the main
file for your object would need to export
an object with verify
and success
functions.
In addition to the lifecycle methods, each lifecyle is passed two objects:
pluginConfig
- an object containing the options that a user may pass in via theirrelease.config.js
file (or similar)context
- provided bysemantic-release
for access to things likeenv
variables set on the running process.
For each lifecycle you create, you will want to ensure it can accept pluginConfig
and context
as parameters.
Creating a Plugin Project
It is recommended that you generate a new project with yarn init
. This will provide you with a basic node project to get started with. From there, create an index.js
file, and make sure it is specified as the main
in the package.json
. We will use this file to orchestrate the lifecycle methods later on.
Next, create a src
or lib
folder in the root of the project. This is where we will store our logic and code for how our lifecycle methods work. Finally, create a test
folder so you can write tests related to your logic.
We recommend you setup a linting system to ensure good javascript practices are enforced. ESLint is usually the system of choice, and the configuration can be whatever you or your team fancies.
Exposing Lifecycle Methods
In your index.js
file, you can start by writing the following code
Then, in your src
folder, create a file called verify.js
and add the following
As of right now, this code won't do anything. However, if you were to run this plugin via semantic-release
, it would run when the verify
step occurred.
Following this structure, you can create different steps and checks to run through out the release process.
Supporting Options
Let's say we want to verify that an option
is passed. An option
is a configuration object that is specific to your plugin. For example, the user may set an option
in their release config like:
This message
option will be passed to the pluginConfig
object mentioned earlier. We can use the validation method we created to verify this option exists so we can perform logic based on that knowledge. In our verify
file, we can add the following:
Supporting Environment Variables
Similar to options
, environment variables exist to allow users to pass tokens and set special URLs. These are set on the context
object instead of the pluginConfig
object. Let's say we wanted to check for GITHUB_TOKEN
in the environment because we want to post to GitHub on the user's behalf. To do this, we can add the following to our verify
command:
Last updated