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

›_

deno bump-version [increment]

The increment argument selects how the version is bumped:

Increment	Example
`patch`	`1.4.6` → `1.4.7`
`minor`	`1.4.6` → `1.5.0`
`major`	`1.4.6` → `2.0.0`
`prepatch`	`1.4.6` → `1.4.7-0`
`preminor`	`1.4.6` → `1.5.0-0`
`premajor`	`1.4.6` → `2.0.0-0`
`prerelease`	`1.4.7-0` → `1.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

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

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

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

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`

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

--base<REF>

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

--config, -c<FILE>

Explicit path to the manifest file to bump. May point to a deno.json/deno.jsonc or a package.json. When set, single-file mode is forced (workspace auto-detection is bypassed). Useful when both deno.json and package.json exist in the same directory.

--dry-run

Print the planned changes without writing any files.

--import-map<PATH>

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

--no-workspace

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

--release-notes<PATH>

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

--start<REF>

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

--workspace, -w

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