standard-version
Automate versioning and CHANGELOG generation
TLDR
Update the changelog file and tag a release
Tag a release without bumping the version
Update the changelog and tag an alpha release
Update the changelog and tag a specific release type
Tag a release, preventing hooks from being verified during the commit step
Tag a release committing all staged changes, not just files affected by standard-version
Update a specific changelog file and tag a release
Display the release that would be performed without performing them
SYNOPSIS
standard-version [options]
PARAMETERS
--help
Displays help information about the command.
--version
Displays the current version of standard-version.
-r, --release-as type
Specify the release type (e.g., major, minor, patch, premajor, preminor, prepatch, prerelease) to force a version bump.
--prerelease identifier
Creates a prerelease version (e.g., beta, alpha) with the specified identifier.
--dry-run
Performs a trial run without making any actual changes to the file system or Git repository. Shows what would happen.
--first-release
Initializes the changelog by generating entries for all previous commits, useful for the very first release.
--skip.tag
Prevents standard-version from creating a Git tag for the new version.
--skip.commit
Prevents standard-version from creating a Git commit for the version bump and changelog update.
--skip.changelog
Prevents standard-version from generating or updating the CHANGELOG.md file.
--no-verify
Bypasses Git commit-hook verification during the commit step.
--preset name
Specifies a conventional commit preset (e.g., angular) for commit message parsing.
--tag-prefix prefix
Customizes the prefix for Git tags (default is 'v', e.g., v1.0.0). Set to empty string for no prefix.
--commit-all
Includes all staged and untracked files in the release commit, not just the version files and changelog.
DESCRIPTION
standard-version is a command-line utility designed to automate the release process for software projects following Semantic Versioning. It streamlines bumping the project's version, generating a CHANGELOG.md file based on Conventional Commits, and creating annotated Git tags. By analyzing your Git commit history, it intelligently determines the next version (patch, minor, or major) and populates the changelog with features, bug fixes, and breaking changes. This automation helps maintain consistent release notes, reduces manual errors, and simplifies the overall software delivery workflow, making it an invaluable tool for continuous integration and deployment pipelines.
CAVEATS
standard-version relies heavily on the Git repository and the Conventional Commits specification. It requires Node.js and is typically installed via npm or yarn. Improper usage or a malformed commit history can lead to unexpected version bumps or incorrect changelog entries. Always use --dry-run first, especially in production environments, to preview changes. It makes permanent changes to your Git history and files.
CONVENTIONAL COMMITS
standard-version expects Git commit messages to adhere to the Conventional Commits specification. This standard provides a lightweight convention on top of commit messages, enabling automated tools to determine the semantic version bump (patch, minor, major) and generate changelogs. Examples: 'feat(scope): add new feature', 'fix(auth): correct login bug', 'BREAKING CHANGE: API updated'.
TYPICAL WORKFLOW
A common workflow involves:
1. Making code changes and committing them using Conventional Commits.
2. Ensuring all desired changes are committed.
3. Running standard-version. This command will:
a. Determine the next version based on commit messages.
b. Update package.json (or other configured files) with the new version.
c. Generate or update CHANGELOG.md.
d. Create a Git commit with the version bump and changelog changes.
e. Create an annotated Git tag for the new version.
4. Pushing the new commit and tag to the remote repository (e.g., git push --follow-tags origin master).
HISTORY
Born from the JavaScript ecosystem's need for automated release processes, standard-version emerged as a popular tool building upon the success of the conventional-changelog project. It simplifies the often-manual and error-prone tasks of semantic versioning and changelog generation. Its development focused on integrating seamlessly with Git and the Conventional Commits specification, providing a single command to handle the full release lifecycle from version bump to tag creation. It has evolved with the community's adoption of standardized commit message formats.