Skip to content

differences-from-changesets.md

Latest commit

 

History

History
207 lines (125 loc) · 13.8 KB

differences-from-changesets.md

File metadata and controls

207 lines (125 loc) · 13.8 KB

Differences from Changesets

Bumpy is built as a modern successor to changesets. This document tracks the pain points, missing features, and design problems in changesets that bumpy addresses (or plans to address), with links back to the relevant GitHub issues.

Implemented

Sane dependency bump propagation

Changesets hardcodes aggressive behavior: a minor bump on a package triggers a major bump on all packages that peer-depend on it. This is the single biggest community complaint.

Bumpy splits propagation into three phases inside an iterative loop:

  • Phase A (always runs): fixes broken version ranges — peer dep bumps match the triggering bump level, regular deps get patch, dev deps are skipped. Cannot be disabled.
  • Phase B: enforces fixed/linked group constraints.
  • Phase C (opt-in): proactive propagation via configurable dependencyBumpRules and cascadeTo rules. Off by default (updateInternalDependencies: "out-of-range").

Key differences from changesets:

  • Out-of-range peer dep bumps match the triggering bump level (not always major) — a minor bump on core → minor bump on plugin, not major
  • Dev deps never propagate by default (configurable per-package for bundled devDeps)
  • cascadeTo config for source-side "when I change, cascade to these packages"
  • Per-bump-file none to acknowledge changes without triggering a direct bump
  • Warns about ^0.x caret range gotchas and workspace:* on peer deps

See docs/version-propagation.md for the full algorithm.

Custom publish commands

Changesets is hardcoded to npm publish. Bumpy supports per-package custom publish commands for VS Code extensions, Docker images, JSR, private registries, or anything else.

Workspace protocol resolution

Changesets uses npm publish even in Yarn/pnpm workspaces, so workspace:^ and catalog: protocols are NOT resolved, resulting in broken published packages. Bumpy resolves all workspace protocols correctly before publish.

Non-interactive CLI

bumpy add works fully non-interactively for CI/CD pipelines and AI-assisted development.

Provenance, staged publishing, and custom publish args

Bumpy has first-class provenance and npmStaged config options, plus support for passing extra args to the publish command.

Topological publish order

Packages are published in dependency order so a partial failure doesn't leave the registry in a broken state.

  • changesets#238 — publish order should respect dependency graph (11 comments)

Default access: public

Bumpy defaults to "access": "public" since most open-source packages are public. Changesets defaults to "restricted".

Publish dry run

bumpy publish --dry-run previews what would be published without actually doing it.

Filtered/individual package publishing

bumpy publish --filter "@myorg/core" publishes only matching packages. Supports globs. Important for partial failure recovery and large monorepos.

Lockfile update after version

bumpy version automatically runs pnpm install --lockfile-only / bun install / etc. to keep the lockfile in sync with bumped versions.

Dates in changelog entries

Bumpy includes the release date in every changelog heading by default.

Migration tool

bumpy init detects .changeset/ and automatically migrates — renaming the directory to .bumpy/, converting config, and keeping pending bump files.

  • (Previously listed under Planned)

Auto-generate from commits

bumpy generate scans commits on the current branch and auto-creates bump files. It works with any commit style — conventional commits get enhanced bump-level detection (feat → minor, fix → patch, feat! → major), while all other commits are mapped to packages via changed file paths (defaulting to patch). Not a replacement for explicit bump files — a bridge for teams migrating from semantic-release, or a convenience when you want both.

  • changesets#862 — conventional commits integration (70 thumbs-up, 21 comments)

Pluggable changelog formatters

Custom changelog formatters with full context (release info, bump files, dates). Built-in "default" and "github" (with PR links + author attribution) formatters. Users can write custom formatters in TypeScript or JavaScript. Changesets' API is limited to two awkward string-returning functions — bumpy gives you the full context and you return the complete entry.

CI without a separate action or bot

Changesets requires two separate pieces of CI infrastructure beyond the CLI:

  1. changeset-bot — a GitHub App you must install on your repo that watches PRs and posts "missing changeset" comments
  2. changesets/action — a GitHub Action (separate repo) that handles creating the version PR and publishing

This means you're trusting and auditing two additional dependencies with write access to your repo. The bot requires GitHub App installation (org admin approval in many orgs), and the action is a separate repository with its own release cadence and issues.

Bumpy replaces all of this with two CLI commands you run directly in standard workflows — bumpy ci check (PR comments) and bumpy ci release (version PR + publishing). No GitHub App to install, no separate action to trust. Your CI runs the same @varlock/bumpy package you already depend on. Works on any CI provider that can run shell commands — not just GitHub Actions.

Prerelease channels that actually work

Changesets' prerelease mode is described in their own docs as "very complicated" with "mistakes that can lead to repository and publish states that are very hard to fix." Key problems: global mode state poisons unrelated merges, exiting pre bumps ALL packages, counters require committed state, dist-tags can't be controlled.

Bumpy replaces the mode with branch-based channels (docs/prereleases.md): a long-lived branch (e.g. next) maps to a prerelease line. Bump file location (.bumpy/<channel>/) is the only state; prerelease versions are never committed — targets derive from bump files, counters from the registry. Promotion to stable is just a merge.

Local bump file verification

bumpy check verifies that changed packages on the current branch have corresponding bump files. Compares your branch to the base branch, maps changed files to packages. By default it only fails if no bump files exist at all (matching changesets behavior). Use --strict to require every changed package to be covered, --no-fail for advisory-only mode, or --hook pre-commit/--hook pre-push to control which bump files count based on their git status. No GitHub API needed.

Changesets has no built-in equivalent — users rely on the CI bot comment to catch missing bump files after pushing.

Planned / Not Yet Implemented

Root workspace / non-package changes

Track changes to CI, tooling, and monorepo-root-level config in changelogs — not just workspace packages.

Non-JS ecosystem support

Support versioning and publishing beyond npm — Rust crates, .NET NuGet, Python packages, etc. — via a package manifest that doesn't require wrapper package.json files.

Maintenance / release branch workflows

Support for hotfixing older major versions on release branches.

Changesets bugs we avoid by design

"Does master exist?" CI failures

Bumpy doesn't shell out to git for branch comparisons during normal operations.

Infinite loop in version command

Bumpy's iterative propagation has a hard iteration cap.