Skip to main content
On this page

deno bump-version

The deno bump-version command updates the version field in your project's configuration file, similar to npm version. It reads and writes the version field in deno.json(c) if present, otherwise it falls back to package.json.

Caution

deno bump-version is experimental and subject to change.

Usage Jump to heading

>_
deno bump-version [increment]

The increment argument selects how the version is bumped:

Increment Example
patch 1.4.61.4.7
minor 1.4.61.5.0
major 1.4.62.0.0
prepatch 1.4.61.4.7-0
preminor 1.4.61.5.0-0
premajor 1.4.62.0.0-0
prerelease 1.4.7-01.4.7-1

If increment is omitted, the current version is printed and the configuration file is left unchanged.

If the configuration file has no version field and an increment is given, the version defaults to 0.1.0.

The command exits with an error if neither deno.json nor package.json is found in the current directory.

Examples Jump to heading

Release a patch:

>_
deno bump-version patch

Cut a new minor release:

>_
deno bump-version minor

Iterate on a prerelease:

>_
deno bump-version prerelease

Print the current version without modifying the file:

>_
deno bump-version

After bumping, commit the updated configuration file as part of your release. For publishing the bumped version to JSR, see deno publish; for an npm tarball, see deno pack.

Workspace mode Jump to heading

When run at the root of a workspace, deno bump-version operates on every member package in a single pass instead of just the root config:

  • The same increment is applied to each member's version field.
  • jsr: version constraints in the workspace root config and in any import map are rewritten in place so cross-package references keep matching the bumped versions.
  • Members without a version field are left alone.
>_
# At the workspace root: patch every member from 1.4.6 to 1.4.7
deno bump-version patch

This avoids the manual coordination step where a workspace release used to require updating each member's deno.json/package.json and the root import map one at a time.

Deriving bumps from Conventional Commits Jump to heading

Inside a workspace, running deno bump-version with no increment argument switches to deriving per-package bumps from Conventional Commits between a base ref and the current branch. Each member's bump is computed independently from the commits that touched files inside it (honoring scoped commits and wildcard * scopes), and the bumped versions are written back to the member configs and any import-map constraints.

The derivation rules:

  • fix: and other patch-level types → patch.
  • feat:minor.
  • A commit marked BREAKING CHANGE: in the body or with a ! after the type (e.g. feat!:) → major.
  • For packages still on 0.x.y, semver rules are applied conservatively: a breaking change yields a minor bump rather than major, and a feat: yields patch.
  • Prereleases (-0, -1, …) get a prerelease increment.
  • Any manual edits to a package's version since the base ref are treated as authoritative and skipped — the tool won't overwrite a deliberate version pick.
>_
# Derive the bumps from commits between `main` and the current branch
deno bump-version --base=main

Selecting the range Jump to heading

Two flags pin the comparison range when the default (the current branch since the latest tag) isn't what you want:

  • --base=<ref> — the ref to compare against. Usually a release branch or tag (--base=main, --base=v1.4.7).
  • --start=<ref> — the ref where the changeset begins. Defaults to the merge base between --base and HEAD.
>_
# Bump based on commits between v1.4.7 and the current branch
deno bump-version --base=v1.4.7

# Bump based on commits between two explicit refs
deno bump-version --base=v1.4.7 --start=release/1.5

--dry-run Jump to heading

Pass --dry-run to print the planned changes — which packages would bump, the old/new version pairs, and the rewritten jsr: constraints — without writing anything to disk:

>_
deno bump-version --base=main --dry-run

This is a good fit for CI checks ("does this branch produce the bumps we expect?") and for previewing a release locally before committing.

Command line usage:
deno bump-version [OPTIONS] [increment]

Update version in the configuration file.

deno bump-version patch
# 1.4.6 -> 1.4.7
deno bump-version minor
# 1.4.6 -> 1.5.0
deno bump-version major
# 1.4.6 -> 2.0.0
deno bump-version prepatch
# 1.4.6 -> 1.4.7-0
deno bump-version preminor
# 1.4.6 -> 1.5.0-0
deno bump-version premajor
# 1.4.6 -> 2.0.0-0
deno bump-version prerelease
# 1.4.7-0 -> 1.4.7-1

When invoked at a workspace root, the same increment is applied to every member package and jsr: references in the root import map are updated. Without an increment, per-package bumps are derived from conventional commit messages between the latest tag and the current branch and a release note is prepended to Releases.md.

Options Jump to heading

--base<REF>
Jump to heading

[conventional-commits mode] Git ref to compare against. Default: current branch.

Print the planned changes without writing any files.

--import-map<PATH>
Jump to heading

Path to the import map to rewrite jsr: version constraints in. Defaults to the root deno.json (or its importMap target).

--no-workspace
Jump to heading

Disable workspace mode and only bump the deno.json/package.json in the current directory.

--release-notes<PATH>
Jump to heading

[conventional-commits mode] Path to the release notes file to prepend. Default: Releases.md.

--start<REF>
Jump to heading

[conventional-commits mode] Git ref to start from. Default: latest tag (git describe --tags`` --abbrev=0).

--workspace, -w
Jump to heading

Bump every package in the workspace (auto-detected at the workspace root).

Last updated on

Did you find what you needed?

Privacy policy