semantic-release shareable config to publish npm packages with GitHub using conventional commits standard.
- Allow running dry run (release predict) on any branch
- Commits are analyzed with conventional commits parser, configuration extended so that
refactor&styletypes increase patch version - Release notes are generated and written to che changelog covering all the common commit types relevant to the consumer
- Automatically generated changelog
- Publishes to a npm package registry
- Creates a Github release
- Pushes
package.jsonandCHANGELOG.mdfile to git
You can install this config via npm or yarn:
npm install semantic-release-config-conventional --save-dev
# or
yarn add semantic-release-config-conventional --devThe shareable config can be configured in the semantic-release configuration file:
To use this configuration in your project, create a Prettier configuration file
(e.g., .prettierrc.js) and extend semantic-release-config-conventional:
// .releaserc.js
module.exports = {
extends: "semantic-release-config-conventional"
};This config can be provided with some options through environment variables
// .releaserc.js
process.env.SR_CONFIG_NPM_PUBLISH = "false"; // if set to false will not attempt to publish a package to the registry
process.env.SR_CONFIG_NPM_PUSH = "true"; // if set to false will disable pushing of the package.json and changelog files after releasing
process.env.SR_CONFIG_CHANGELOG_FILE = "CHANGELOG.md"; // defines the path for the changelog file
module.exports = {
extends: "semantic-release-config-conventional"
};See each plugin documentation for required installation and configuration steps.
This shareable configuration uses the following plugins (with internal configurations applied):
@semantic-release/commit-analyzer@semantic-release/release-notes-generator@semantic-release/changelog@semantic-release/npm@semantic-release/github@semantic-release/git
For optimal experience and consistency with sematic release, it is suggested to add commit validation matching the standard applied to semantic-release, in this case conventional-commits.
Ideally the releases should be performed through CI/CD workflows, reducing the possibility of human error. The commit validation should also run on the CI/CD workflows.
Check the example/recipe.
If you encounter any issues with this ESLint configuration or have suggestions for improvements, please visit the GitHub repository and open an issue or pull request. Check also the development docs.