📦 🚀 semantic-release
fully automated package publishing
Trust us, this will change your workflow for the better.
– egghead.io
Out of the box this is just about commit-messages, but you can do so much more.
- Detect breaking changes using the test suite of your last release: cracks
- Detect breaking changes using your dependents’ test suites: Help out! Implement the dont-break plugin
- Detect breaking changes diffing your JSDoc interface: Help out! Implement the india plugin
- Abort releases with insufficient test coverage: Help out! Implement the istanbul plugin
- Abort releases with vulnerable dependencies in the tree: Help out! Implement the nsp plugin
- Everything you can imagine: Build Plugins!
Commands | Comment | |
---|---|---|
manual/before |
|
You manually decide what the next version is. You have to remember what major, minor and patch means. You have to remember to push both commits and tags. You have to wait for the CI to pass. |
semantic-release/after |
|
You describe the changes you’ve made. A new version is automatically published with the correct version number. |
This removes the immediate connection between human emotions and version numbers, so strictly following the SemVer spec is not a problem anymore – and that’s ultimately semantic-release
’s goal.
How does it work?
Instead of writing meaningless commit messages, we can take our time to think about the changes in the codebase and write them down. Following formalized conventions it is then possible to generate a helpful changelog and to derive the next semantic version number from them.
When semantic-release
is set up it will do that after every successful continuous integration build of your master branch (or any other branch you specify) and publish the new version for you. This way no human is directly involved in the release process and your releases are guaranteed to be unromantic and unsentimental.
If you fear the loss of control over timing and marketing implications of software releases you should know that semantic-release
supports release channels using npm
’s dist-tags. This way you can keep control over what your users end up using by default, you can decide when to promote an automatically released version to the stable channel, and you can choose which versions to write blogposts and tweets about. You can use the same mechanism to support older versions of your software, for example with important security fixes.
This is what happens in series:
1. git push |
2. semantic-release pre |
3. npm publish |
4. semantic-release post |
---|---|---|---|
New code is pushed and triggers a CI build. | Based on all commits that happened since the last release, the new version number gets written to the package.json . |
The new version gets published to npm . |
A changelog gets generated and a release (including a git tag) on GitHub gets created. |
Note: The current release/tag implementation is tied to GitHub, but could be opened up to Bitbucket, GitLab, et al. Feel free to send PRs for these services.
Default Commit Message Format
This module ships with the AngularJS Commit Message Conventions and changelog generator, but you can define your own style.
Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject (full explanation):
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
You can simplify using this convention for yourself and contributors by using commitizen and commitlint or semantic-git-commit-cli.
Patch Release
fix(pencil): stop graphite breaking when too much pressure applied
Minor Feature Release
feat(pencil): add 'graphiteWidth' option
Major Breaking Release
perf(pencil): remove graphiteWidth option
BREAKING CHANGE: The graphiteWidth option has been removed. The default graphite width of 10mm is always used for performance reasons.
Setup
npm install -g semantic-release-cli
cd your-module
semantic-release-cli setup
This is what happens under the hood.
Options
You can pass options either via command line (in kebab-case) or in the release
field of your package.json
(in camelCase). The following two examples are the same, but CLI arguments take precedence.
CLI | package.json |
---|---|
|
|
These options are currently available:
branch
: The branch on which releases should happen. Default:'master'
debug
: If true doesn’t actually publish to npm or write things to file. Default:!process.env.CI
githubToken
: The token used to authenticate with GitHub. Default:process.env.GH_TOKEN
githubUrl
: Optional. Pass your GitHub Enterprise endpoint.githubApiPathPrefix
: Optional. The path prefix for your GitHub Enterprise API.
A few notes on npm
config:
-
The
npm
token can only be defined in the environment asNPM_TOKEN
, because that’s wherenpm
itself is going to read it from. -
In order to publish to a different
npm
registry you can specify that inside thepackage.json
’spublishConfig
field. -
If you want to use another dist-tag for your publishes than
'latest'
you can specify that inside thepackage.json
’spublishConfig
field. -
semantic-release
generally tries to orientate itself towardsnpm
– it inherits the loglevel for example.
Plugins
There are numerous steps where you can customize semantic-release
’s behaviour using plugins. A plugin is a regular option, but passed inside the release
block of package.json
:
{
"release": {
"analyzeCommits": "npm-module-name",
"generateNotes": "./path/to/a/local/module",
"verifyConditions": {
"path": "./path/to/a/module",
"additional": "config"
}
}
semantic-release pre --analyze-commits="npm-module-name"
A plugin itself is an async function that always receives three arguments.
module.exports = function (pluginConfig, config, callback) {}
pluginConfig
: If the user of your plugin specifies additional plugin config in thepackage.json
(see theverifyConditions
example above) then it’s this object.config
: A config object containing a lot of information to act upon.env
: All environment variablesnpm
: Select npm configuration bits likeregistry
,tag
andauth
options
:semantic-release
options likedebug
, orbranch
pkg
: Parsedpackage.json
- For certain plugins the
config
object contains even more information. See below.
callback
: If an error occurs pass it as first argument. Otherwise pass your result as second argument.
analyzeCommits
This plugin is responsible for determining the type of the next release. It additionally receives a commits
array inside config
. One commit is an object with a message
and hash
property. Call the callback with 'major'
, 'premajor'
, 'minor'
, 'preminor'
, 'patch'
, 'prepatch'
, 'prerelease'
, or null
if nothing changed.
While it may be tempting to use 'prepatch'
, 'preminor'
& 'prerelease'
as part of a release process, this is strongly discouraged. A better approach is to use dist-tags to create release channels (such as 'latest', 'next', 'stable') and to return only 'major'
, 'premajor'
and 'minor'
from the commit analyzer.
Have a look at the default implementation.
generateNotes
This plugin is responsible for generating release notes. Call the callback with the notes as a string. Have a look at the default implementation.
verifyConditions
This plugins is responsible for verifying that a release should happen in the first place. For example, the default implementation verifies that the publish is happening on Travis, that it’s the right branch, and that all other build jobs succeeded. There are more use cases for this, e.g. verifying that test coverage is above a certain threshold or that there are no vulnerabilities in your dependencies. Be creative.
Passing an array of plugins will run them in series.
verifyRelease
This plugin is responsible for verifying a release that was determined before and is about to be published. There is no default implementation. It additionally receives nextRelease
, lastRelease
and commits
inside config
. While commits
is the same as with analyzeCommits, nextRelease
contains a type
(e.g. 'major'
) and the new version (e.g. '1.0.0'
) and lastRelease
contains the old version
, the gitHead
at the time of the release and the npm dist-tag
(e.g. 'latest'
). Using this information you could detect breaking changes or hold back certain types of releases. Again: Be creative.
Passing an array of plugins will run them in series.
getLastRelease
This plugin is responsible for determining a package’s last release version. The default implementation uses the last published version on a npm registry.
ITYMFAQLT
I think you might frequently ask questions like these
package.json
’s version not updated in my repository?
Why is the The npm
docs even state:
The most important things in your package.json are the name and version fields. Those are actually required, and your package won’t install without them. – npm docs
While this entirely true the version number doesn’t have to be checked into source control. semantic-release
takes care of the version field right before npm publish
uses it – and this is the only point where it really is required.
Is there a way to preview which version would currently get published?
If you run npm run semantic-release
locally a dry run gets performed, which logs the version that would currently get published.
Can I run this on my own machine rather than on a CI server?
Of course you can, but this doesn’t necessarily mean you should. Running your tests on an independent machine before releasing software is a crucial part of this workflow. Also it is a pain to set this up locally, with tokens lying around and everything. That said, you can run the scripts with --debug=false
explicitly. You have to export GH_TOKEN=<your_token>
and NPM_TOKEN=<your_other_token>
.
Can I manually trigger the release of a specific version?
You can trigger a release by pushing to your GitHub repository. You deliberately cannot trigger a specific version release, because this is the whole point of semantic-release
. Start your packages with 1.0.0
and semver on.
Is it really a good idea to release on every push?
It is indeed a great idea because it forces you to follow best practices. If you don’t feel comfortable making every passing feature or fix on your master branch addressable via npm
you might not treat your master right. Have a look at branch workflows. If you still think you should have control over the exact point in time of your release, e.g. because you are following a release schedule, you can release only on the production
/deploy
/release
branch and push your code there in certain intervals, or better yet use dist-tags.
semantic-release
with my releases?
Why should I trust semantic-release
has a full unit- and integration-test-suite that tests actual npm
publishes against the npm-registry-couchapp. A new version won’t get published if it doesn’t pass on all these engines.
semantic-release
require node version >= 8
Why does Being able to write code for just the most recent node versions greatly simplifies development. More language features are available, no transpilation is required, less test builds are to be run, awaited and debugged.
For a special purpose tool like semantic-release
, that's only meant to be used in controlled CI environments, we think it's okay to have such a high version requirement. As semantic-release
handles package publishing we expect almost every project to have at least one build job running node 8 already – and that's all it takes. Even if that's not that case semantic-release
can still be executed with the help of npx (npx -p node@8 npm run semantic-release
).
Badge
Use this in one of your projects? Include one of these badges in your README.md to let people know that your package is published using semantic-release
.
[![semantic-release](https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg)](https://github.com/semantic-release/semantic-release)
[![semantic-release](https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg?style=plastic)](https://github.com/semantic-release/semantic-release)
[![semantic-release](https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg?style=flat-square)](https://github.com/semantic-release/semantic-release)
License
MIT License 2015 © Stephan Bönnemann and contributors