Taze: keeping npm, JSR and GitHub Actions dependencies fresh from the command line

What Taze solves, and who it is for

Dependency drift is boring work. You have a package.json with ranges, a lockfile, a monorepo with several workspaces, a set of GitHub Actions pinned to tags, and a .nvmrc that nobody has touched in a year. Taze is a CLI that reports and rewrites those versions. The README describes it as "a modern cli tool that keeps your deps fresh", and the package.json description is more specific: "A modern CLI tool that keeps your dependencies fresh in any repo and monorepo".

The intended user is an engineer who already knows their package manager. Taze does not install dependencies, run tests, or resolve a lockfile. It reads manifests, asks registries what versions exist, and writes version strings back into package.json or workflow files. That narrow scope is the point: it can be run through npx with no installation, and it can be run in a monorepo with one flag. It is also designed to be consumed by automation, since --json produces machine-readable output for agents and CI.

How Taze decides what to bump: ranges, modes and maturity

The default behaviour is deliberately conservative. According to the README, "By default, taze will only bump versions in the ranges you specified in package.json (which is safe and the default behavior of npm install)". If your manifest says ^18.0.0 and the latest is 19.2.0, a plain taze run will not move you there. To cross that boundary you pass a mode: taze major checks all changes including majors, taze minor stays within the same major version, and taze patch stays within the same minor. The mode is the explicit opt-in to breaking changes.

Two filters shape the result further. Locked versions, meaning a fixed version with no ^ or ~, are skipped by default and only appear with --include-locked or -l. Peer dependencies are also excluded unless you pass --peer, because bumping a peer range changes what your package promises to consumers. There is a separate maturity filter: --maturity-period hides versions younger than 7 days, and --maturity-period 14 widens that window. The README notes that other tools call this filtering cooldown or minimumReleaseAge, and that exclusions can be inferred from package manager configuration such as minimumReleaseAgeExclude in pnpm-workspace.yaml and npmPreapprovedPackages in .yarnrc.yml.

Filtering by package name accepts strings and regexes separated by commas, and there is a version-range form that is easy to miss:

taze --include lodash,webpack
taze --include /react/ --exclude react-dom
taze --exclude typescript@7
taze --exclude "typescript@^7||^8"

The third and fourth examples exclude only a version range of a package rather than the whole package, which lets you block a major version while still receiving minor and patch updates. Dependencies listed in pnpm's update.ignoreDeps in pnpm-workspace.yaml are excluded automatically, so Taze inherits a policy you already wrote for pnpm.

Installing Taze and running a first check

There is no install step in the usual sense. The README's first example is npx taze, and the monorepo example is npx taze -r. If you prefer a local binary, the package exposes a taze bin entry pointing at bin/taze.mjs, so a normal package-manager install puts the command on your path.

Start with a read-only check in a single package. The default run prints a table of outdated dependencies without writing anything:

npx taze

You should see the default table described in the README, listing packages whose newer versions fall inside your declared ranges. If nothing is listed, either everything is current within range or the remaining updates are outside your ranges and need a mode.

For a monorepo, add -r. The README states that this scans subdirectories containing package.json and updates them together, handling local private packages automatically:

npx taze -r

To see major updates before committing to them, pass the mode. This reports what a major bump would look like:

npx taze major

When you are ready to write, add -w. Combining it with a mode is the README's own example for GitHub Actions, and the same flag writes package.json changes:

taze major -w

For CI or an agent, use JSON output. The README notes that --json disables interactive mode and suppresses progress bars, tables and tips, and that only dependencies with an available update are included unless you add --all:

npx taze -r --json

Interactive selection is available when you want to choose packages by hand rather than accept a whole mode.

Monorepos, GitHub Actions and JSR in the same run

The recursive flag is the feature that separates Taze from a single-package updater. With -r it walks subdirectories that contain a package.json and treats them as one job, which means a workspace with a shared catalog and several apps gets one report instead of one run per package.

The GitHub Actions support is more unusual. When a .github/workflows directory exists, Taze scans .github/workflows/*.{yml,yaml}, composite actions under .github/actions/**/action.{yml,yaml}, a repo-root action.{yml,yaml}, and reusable workflow calls. It reports newer action versions next to npm dependencies, and it works in every mode plus --interactive, --json and -w. References are rewritten at the granularity you wrote: @v4 becomes @v5, and @v4.1.1 becomes @v4.2.0. By default the existing style is preserved, so tag references stay tags and SHA-pinned references stay pinned with a refreshed version comment. You can force a style:

# style: sha — pin to an immutable commit for supply-chain safety
- uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
# style: tag
- uses: actions/checkout@v5

The scope of that rewriting is bounded. Only v-prefixed version tags are considered, so branch refs such as @main, non-v tags, docker:// actions and local ./ actions are left untouched. Action versions come from the GitHub REST API, and the README states that setting GITHUB_TOKEN or GH_TOKEN raises the rate limit from 60 to 5000 requests per hour. If neither is set, Taze falls back to a token from the GitHub CLI via gh auth token when you are logged in. Filtering, the maturity cooldown and the mode all apply to actions too, matched by the action's owner/repo name. JSR dependencies are checked alongside npm ones, including the native jsr: protocol.

Where Taze stops short

The safe default is also the sharpest limitation. A plain npx taze will report almost nothing in a repository whose ranges are already current, and it will silently skip locked versions and peerDependencies. If you expect a single command to show every available upgrade, you will misread an empty or short table as "everything is fine". The README is explicit about all three behaviours, but they are easy to forget when the command is run from a script that nobody reads.

Taze also does not verify that an update works. It writes version strings; it does not install, build or test. The README does not document rollback, so recovery depends on your own version control rather than on the tool. There is no lockfile resolution step either, which means the lockfile is left for your package manager to update afterwards. If your workflow depends on a single tool that updates manifests and lockfiles together, Taze is the wrong half of that pair.

Rate limits are a practical constraint for the GitHub Actions path. Without a token, the GitHub REST API allows 60 requests per hour, which a large workflow directory can exhaust. The fallback to gh auth token only helps if the GitHub CLI is installed and authenticated. Finally, the maturity filter is a delay, not a safety guarantee: a version that has been out for 14 days is not thereby compatible with your code.

How Taze differs from Dependabot and Renovate

The closest alternatives are hosted or bot-driven update services such as Dependabot and Renovate. The difference is where the work happens. Those tools run on a schedule in your repository host, open pull requests, and leave a review trail; Taze runs when you invoke it, prints a table or JSON to your terminal, and writes changes into your working tree. There is no pull request, no schedule and no server-side state.

That changes the review model. With a bot you review a diff that already exists as a branch. With Taze you review the output of a command before adding -w, or you inspect the working tree afterwards. For a monorepo with local private packages, Taze's -r flag handles the workspace graph directly, whereas a bot configuration has to be taught the same structure. On the other hand, a bot keeps running when nobody remembers to run a command, and Taze will not.

The two are not mutually exclusive in principle, but running both against the same manifests means competing writers. Pick one as the source of truth for version bumps.

Licence, maintenance and upgrade cost

Taze is MIT licensed, with the licence file at the repository root and the licence field set to MIT in package.json. That permits commercial use and modification with the usual attribution requirement; it says nothing about the licences of the dependencies Taze updates, which remain your responsibility to check.

The repository is not archived, and the last push was on 2026-09-20. The most recent release listed is v21.1.0 from 2026-08-14, following v21.0.0 and v20.0.2 on the same day. The project uses pnpm and a workspace catalog for its own dependencies, and the release script is bumpp, so versioning is automated.

Upgrade cost is low for the CLI itself because it is invoked through npx and holds no state. The cost that matters is behavioural: a new major of Taze can change what a mode includes or how filtering parses, and the README is the only contract. Pinning the version in CI rather than relying on npx's latest resolution gives you a reproducible report.

Editorial conclusion

Adopt Taze if you want one command that reports and rewrites npm, JSR and GitHub Actions versions across a monorepo, and you are comfortable that the default run only moves within your existing ranges. Do not adopt it if you need a tool that also runs install, tests or lockfile resolution as part of the update. Before trusting it on a real branch, run npx taze -r --json on a clean checkout and compare the reported updates against your package.json ranges, then confirm whether locked versions and peerDependencies need --include-locked or --peer.

Frequently asked questions

Official sources

1. antfu-collective/taze on GitHub
2. Issues
3. License: MIT
4. README
5. Releases