Bumpy: zero-config monorepo releases powered by Git history

--- title: "Bumpy: zero-config monorepo releases powered by Git history" published: true description: "Zero-config, Git-powered versioning for monorepos" tags: javascript, monorepo, devops, opensource # cover_image: https://direct_url_to_image.jpg # Use a ratio of 100:42 for best results. # published_at: 2026-01-26 08:30 +0000 --- Hi there! Monorepo releases can be amazing… until the tooling feels either too heavy (extra metadata, intent files, complex flows) or too opinionated about _how_ you should work. I wanted something lightweight that stays out of the way — especially if your Git history is already meaningful. So I built **Bumpy** — a **zero-config CLI for monorepo versioning** that: - **Auto-discovers packages** (pnpm/npm workspaces, `apps/*`, `packages/*`) - **Suggests the next version** using Conventional Commits - **Generates per-package changelogs** from Git history - **Uses per-project tags** like `project@version` for precise release boundaries - **Supports prereleases** and `--dry-run` **Repo:** [https://github.com/antonreshetov/bumpy](https://github.com/antonreshetov/bumpy) **Best fit:** small/medium monorepos that already use Conventional Commits and want clean per-package changelogs + tags, without adopting a whole new workflow. ## Why another release tool? Tools like **Changesets** and **Nx Release** are excellent — they just optimize for different trade-offs than I needed: - **Changesets:** great, but it’s a _file-based workflow_ (changeset “intent” markdown files that you commit and later assemble into releases). - **Nx Release:** powerful and well-integrated if you’re already in Nx; heavier if your repo isn’t. Bumpy tries to keep the best parts (automation + safety) while keeping Git as the source of truth and avoiding extra ceremony. ## How Bumpy works At release time, Bumpy: 1. **Scan:** Finds packages in your workspace. 2. **Locate:** Detects the last tag for each package (e.g., `[email protected]`). 3. **Analyze:** Reads Git history since that tag. 4. **Suggest:** Recommends a bump based on Conventional Commits. 5. **Generate:** Creates/updates a package-level `CHANGELOG.md`. You can always confirm the suggestion, choose a different bump type, or enter a custom version. ## Quick Start ### Installation ```bash # Global npm install -g @antonreshetov/bumpy # Local (recommended for monorepos) pnpm add -D @antonreshetov/bumpy ``` ### Common commands - **Interactive release:** `bumpy` - **Status overview:** `bumpy status` - **Release one project (non-interactive):** `bumpy release project-a --type minor --yes` - **Dry-run:** `bumpy release --dry-run` ## Config is optional By default, Bumpy uses your existing workspace layout. To customize behavior, run `bumpy init` to generate `bumpy.json` in the repo root. ```json { "projects": ["apps/*", "packages/*"], "release": { "ignore": ["apps/internal-tool"], "changelog": { "projectChangelogs": true, "workspaceChangelog": false }, "git": { "commit": true, "tag": true, "push": true, "commitMessage": "chore(release): {tag}" } } } ``` ## Where I’d love feedback If you’ve used Changesets / Nx Release / anything similar: - Does this release flow feel intuitive? - What would you _miss_ immediately if you switched to Bumpy? - Any edge cases you’ve hit around per-project tags or changelog structure? - What should `bumpy status` show to be useful day-to-day? Repo again: [https://github.com/antonreshetov/bumpy](https://github.com/antonreshetov/bumpy)