I’m the author of Bumpy, a zero-config CLI tool for automating versioning and changelogs in monorepos.
The Problem: Monorepo tooling often feels too heavy. While tools like Changesets are excellent, they rely on a file-based workflow (creating "intent" markdown files), which adds extra steps. Nx Release is powerful but feels heavy if you aren't already fully bought into the Nx ecosystem.
The Solution: I wanted something that treats Git history as the source of truth without extra metadata files. Bumpy is designed for small to medium monorepos that already use Conventional Commits.
How it works:
- Auto-discovery: Finds packages (pnpm/npm workspaces, apps/*, etc.).
Analysis: Detects the last tag (e.g., project@version) and reads commits since then.
- Suggestion: Proposes the next version based on commit messages (Conventional Commits).
- Generation: Updates package.json and writes a clean, per-package CHANGELOG.md.
Key Features:
- Zero-config default (but configurable via bumpy.json).
- Supports independent versioning with per-project tags.
- Interactive mode + Dry-run support.
It’s meant to stay out of your way and just automate the release step.
I’d love to get your feedback:
- Does the "Git history as source of truth" flow feel robust enough for your workflows compared to the "intent file" model of Changesets?
- Are there edge cases in per-project tagging you've encountered with other tools?
Show HN: Bumpy, a lightweight alternative to Changesets/Nx Release · HackerTrans
I’m the author of Bumpy, a zero-config CLI tool for automating versioning and changelogs in monorepos.
The Problem: Monorepo tooling often feels too heavy. While tools like Changesets are excellent, they rely on a file-based workflow (creating "intent" markdown files), which adds extra steps. Nx Release is powerful but feels heavy if you aren't already fully bought into the Nx ecosystem.
The Solution: I wanted something that treats Git history as the source of truth without extra metadata files. Bumpy is designed for small to medium monorepos that already use Conventional Commits.
How it works:
- Auto-discovery: Finds packages (pnpm/npm workspaces, apps/*, etc.). Analysis: Detects the last tag (e.g., project@version) and reads commits since then. - Suggestion: Proposes the next version based on commit messages (Conventional Commits). - Generation: Updates package.json and writes a clean, per-package CHANGELOG.md.
Key Features:
- Zero-config default (but configurable via bumpy.json). - Supports independent versioning with per-project tags. - Interactive mode + Dry-run support.
It’s meant to stay out of your way and just automate the release step.
I’d love to get your feedback:
- Does the "Git history as source of truth" flow feel robust enough for your workflows compared to the "intent file" model of Changesets? - Are there edge cases in per-project tagging you've encountered with other tools?