My preferred semantic release config.
npm install @alanscodelog/semantic-release-config

My preferred semantic release config:
- Support for 0.0.0 versioned releases.
- Shows the full commit body in the release notes.
- Uses semantic-release/git to commit the version change (makes packages in monorepos easier to handle).
``bash`
yarn add -D @alanscodelog/semantic-release-config
`js`
// package.json
{
"release": {
"extends": "@alanscodelog/semantic-release-config",
"assets": [
// { path: "", label: "" }
]
// see notes below regarding the passing of global options
}
}
Changelog Header (release type)Shown in Changelog
feat :star: New Features (minor)fix :bug: Fixes (patch)revert :arrow_backward: Reverts (patch)docs :book: Documentation (not released) - not released because they'd get built and published to github pages anywaysdocs(readme) (patch) - published so npm's readme gets updated
perf :rocket: Performance Improvements (patch)
The commit body is shown by default, this can be disabled by setting the SEMANTIC_RELEASE_HIDE_COMMIT_BODY environment variable to TRUE, or per commit by adding to the commit body.
Workaround for semantic-release's lack of 0.0.0 versioning (see).
For the following to work there must be an initial commit tagged v0.0.0 (I usually just make this empty. After, a v0feat: initial commit can be made and semantic release will release it as v0.0.1. So long as you use v0* release types or any release type that is only a patch, you will stay in major version 0.
v0feat :star: New Features (patch)
v0fix :bug: Fixes (patch) - technically a regular fix would also work
v0breaking :warning: BREAKING CHANGES (minor) - use this tag for breaking changes, it looks like a breaking change in release logs but isn't really one for semantic-release.
Do NOT use BREAKING CHANGES in the commit text, it will cause a major version bump.
tests :white_check_mark: Tests (patch)
chore :wrench: Chores (patch)
deps :link: Dependency Updates (patch)
ci :arrows_counterclockwise: CI (patch)
build :hammer: Build (patch)
style :art: Code Style (patch)
refactor :package: Code Refactoring (patch)
any (not released)
- any maintenance branches (x.x.x)
- master
- alpha
- beta
Personally I try to stick with master and beta to keep things simple.
``bash`
@semantic-release/commit-analyzer
@semantic-release/release-notes-generator
@semantic-release/git
@semantic-release/github
@semantic-release/npm
- The @semantic-release/github and @semantic-release/npm` plugins are used in the config without options so global options will be passed down to them, but, for other plugins, it doesn't seem possible to override any options that were already passed down to them.
- Additionally note the debug flag for semantic-release does not seem to reflect the passing of this global options. I have filed an issue regarding all this here