README
versionem
Automated semantic versioning integrated to changelog generation
Summary
Why?
The changelog generation topic certainly has been around for a while, and for sure Node.js ecosystem wouldn't be outside of this, so why choose versionem
(a.k.a the new kid on the block), over other already well-known and trusted tools
Note: not all points listed on the table below might be of your interest, that's just my personal perspective on things, and why
versionem
should be considered as a valid competitor to this scenario, instead of just another wheel reinvention
versionem | semantic-release |
standard-version |
releasy |
|
---|---|---|---|---|
Changelog generation | ✔️ | ✔️ | ✔️ | ✔️ |
Automated semantic version bump | ✔️ | ✔️ | ✔️ | ❌ |
Manual version bump | ✔️ | ❌ | ✔️ | ✔️ |
Changelog regeneration | ✔️ | ✔️ | ❌ | ❓[¹] |
CI integration | ❌ | ✔️ | ❌ | ❌ |
GitHub Releases | ❌ | ✔️ | ⚠️[²] | ✔️ |
- Couldn't get it to work, returned:
[ERROR] Failed to release
, no issues in regard to this problem were found on the repository - Requires
conventional-github-releaser
Installation
yarn:
# Local
$ yarn add -D versionem
# Global
$ yarn global add versionem
npm:
# Local
$ npm i -D versionem
# Global
$ npm i -g versionem
Usage
versionem [path] [--dryRun] [--noPush] [--noTag] [--regenChangelog] [--silent]
Note: You don't need the
path
argument if the project you want to release is in the current directory
Options
--major
- Bumps major version number (x.0.0), equivalent of releasing a breaking change
--minor
- Bumps minor version number (0.x.0), equivalent of releasing a new feature
--patch
- Bumps patch version number (0.0.x), equivalent of releasing a bugfix
--publish
- Publishes the package to npm right after the release
--dryRun
- Run the whole release process without making a single modification to existing files nor creating new ones
--unreleased
- Includes to changelog commits created before a release (implicitly includes both
--noCommit
and--noBump
)
- Includes to changelog commits created before a release (implicitly includes both
--force
- Force release even when there aren't eligible commits
--releasePlaceholder
- Use a custom message for releases that doesn't contain eligible commits
--noPush
- Prevent pushing to remote after release
--noCommit
- Prevent release commit (implicitly includes both
--noTag
and--noPush
)
- Prevent release commit (implicitly includes both
--noLog
- Prevent changelog from being generated
--noTag
- Prevent release commit from being tagged
--noBump
- Prevent
package.json#version
field from being updated
- Prevent
--regenChangelog
- Regenerate all changelogs entries from scratch (overwriting existing ones), useful for existing codebases migrating to
versionem
- Regenerate all changelogs entries from scratch (overwriting existing ones), useful for existing codebases migrating to
--silent
- Don't output any log or message from the CLI (except from errors)
Tips
Including unreleased commits on changelog
For that, Husky is essential, as in contrast to plain Git, it provides a clean and easy way to interact with Git hooks, and also, a special detail that makes it even more important for this to work, is that it allows to skip
post-commit
hookAfter follow Husky setup tutorial, add the
post-commit
hook by running the following command:$ yarn add .husky/pre-commit "versionem --unreleased"