What does --no-git-tag-version do?

It prevents pnpm from creating git tags or commits when updating versions.

What if some packages are already at the target version?

Use --allow-same-version to avoid failures when a package already has the target version.

Should I commit the changes after syncing versions?

Yes. Commit the updated root package.json, all workspace package.json files, and the updated lockfile as part of a release PR.

bumpup-versions

npx machina-cli add skill yu-iskw/coding-agent-fabric/bumpup-versions --openclaw

Files (1)

SKILL.md

2.9 KB

Bumpup Versions Skill

This skill provides a standardized workflow to synchronize and increment version numbers across the entire monorepo (root and all packages) using native pnpm commands.

When to Use

When preparing for a release that requires a unified version bump across all packages.
When you notice version drift between the root package.json and workspace packages.
When requested to "bump versions", "release a new version", or "sync package versions".

Instructions

1. Determine Target Version

Identify if you are performing a semantic bump (patch, minor, major) or setting an explicit version (e.g., 1.0.0).

2. Synchronize Workspace Packages

Run the version command recursively across all packages in the workspace using pnpm -r exec. The --no-git-tag-version flag prevents automatic git tagging and commits, and --allow-same-version ensures it doesn't fail if a package is already at the target version.

pnpm -r exec pnpm version <version_or_bump_type> --no-git-tag-version --allow-same-version

3. Update Root Version

Update the root package.json to match the workspace versions.

pnpm version <version_or_bump_type> --no-git-tag-version --allow-same-version

4. Update Lockfile and Internal References

Run pnpm install to ensure pnpm-lock.yaml is updated with the new versions and any internal workspace dependencies (using workspace:*) are correctly resolved.

pnpm install

5. Verify Changes

Check a sample of package.json files to ensure they all reflect the new version.

grep '"version":' package.json packages/*/package.json packages/plugins/*/package.json

Termination Criteria

The version field in the root package.json matches the target version.
The version field in all packages/**/package.json files matches the target version.
pnpm-lock.yaml has been updated and there are no linting/test regressions related to the version change.

Examples

Scenario: Performing a patch bump across the monorepo

Agent: "I will bump the version to the next patch."
Command: pnpm -r exec pnpm version patch --no-git-tag-version --allow-same-version
Command: pnpm version patch --no-git-tag-version --allow-same-version
Command: pnpm install
Verification: grep '"version":' package.json packages/*/package.json

Scenario: Setting an explicit version (e.g., 0.2.0)

Agent: "Synchronizing all packages to version 0.2.0."
Command: pnpm -r exec pnpm version 0.2.0 --no-git-tag-version --allow-same-version
Command: pnpm version 0.2.0 --no-git-tag-version --allow-same-version
Command: pnpm install

Source

git clone https://github.com/yu-iskw/coding-agent-fabric/blob/main/.claude/skills/bumpup-versions/SKILL.mdView on GitHub

Overview

This skill standardizes and synchronizes version numbers across the root and every workspace package in a pnpm-managed monorepo. It prevents version drift and ensures a unified version for releases by applying the same bump or explicit version everywhere and updating the lockfile accordingly.

How This Skill Works

It uses pnpm -r exec to apply a version bump across all workspace packages, with --no-git-tag-version to avoid automatic tagging and --allow-same-version to prevent failures if a package already has the target version. After syncing the workspace, it updates the root version, runs pnpm install to refresh pnpm-lock.yaml and internal workspace references, and then verifies the changes across package.json files.

When to Use It

When preparing for a release that requires a unified version bump across all packages
When you notice version drift between the root package.json and workspace packages
When you are asked to 'bump versions', 'release a new version', or 'sync package versions'
After merging changes that affect multiple packages to ensure consistent versioning
When you need to align internal workspace dependencies referenced as workspace:*

Quick Start

Step 1: Identify the target version (patch/minor/major or an explicit version)
Step 2: Run workspace and root updates: pnpm -r exec pnpm version <version_or_bump_type> --no-git-tag-version --allow-same-version; pnpm version <version_or_bump_type> --no-git-tag-version --allow-same-version
Step 3: Refresh and verify: pnpm install; grep '"version":' package.json packages/*/package.json

Best Practices

Decide in advance whether you will perform a semantic bump (patch, minor, major) or set an explicit version
Run the workspace version update first, then update the root package.json to match
Always use --no-git-tag-version and --allow-same-version to avoid unintended commits and failures
Run pnpm install afterward to refresh lockfile and internal workspace references
Verify a sample of package.json files (and optionally commit changes in a PR) to ensure consistency

Example Use Cases

Perform a patch bump across all packages: pnpm -r exec pnpm version patch --no-git-tag-version --allow-same-version; pnpm version patch --no-git-tag-version --allow-same-version; pnpm install
Set an explicit version (e.g., 1.2.0) across all packages: pnpm -r exec pnpm version 1.2.0 --no-git-tag-version --allow-same-version; pnpm version 1.2.0 --no-git-tag-version --allow-same-version; pnpm install
After adding a new workspace package, synchronize versions to prevent drift with existing packages
Before releasing a major update, bump all package versions to reflect the new major version
Resolve drift detected during a dependency audit by re-synchronizing root and workspace versions and re-installing

Frequently Asked Questions

Add this skill to your agents