LinuxCommandLibrary

standard-version

Automate versioning and CHANGELOG generation

TLDR

Update the changelog file and tag a release

$ standard-version
copy

Tag a release without bumping the version
$ standard-version --first-release
copy

Update the changelog and tag an alpha release
$ standard-version --prerelease alpha
copy

Update the changelog and tag a specific release type
$ standard-version --release-as [major|minor|patch]
copy

Tag a release, preventing hooks from being verified during the commit step
$ standard-version --no-verify
copy

Tag a release committing all staged changes, not just files affected by standard-version
$ standard-version --commit-all
copy

Update a specific changelog file and tag a release
$ standard-version --infile [path/to/file.md]
copy

Display the release that would be performed without performing them
$ standard-version --dry-run
copy

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.

SEE ALSO

git(1), npm(1), yarn(1), semver(7), conventional-changelog-cli

Copied to clipboard