You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -18,7 +18,18 @@ A modern package versioning and changelog generation tool — built for monorepo
18
18
19
19
## How It Works
20
20
21
-
Bumpy uses **bump files** (you may know them as "changesets" if coming from that tool) — small markdown files that declare which packages changed and how (patch/minor/major), along with a description that ends up in changelogs. Developers create these files as part of their PRs. As PRs merge to the base branch, a "release PR" is kept up to date showing what packages will be released and their changelogs — including packages bumped automatically due to dependency relationships. When the release PR is merged, bump files are consumed (deleted), and packages are published with updated versions and changelogs.
21
+
Bumpy uses **bump files** (you may know them as "changesets" if coming from [that tool 🦋](https://github.com/changesets/changesets)) — small markdown files that declare an intent to release packages with a bump level (patch/minor/major), and a description that ends up in changelogs. Developers create these files as part of their PRs, and these files are then used to consolidate changes, generate changelogs, and trigger publishing. Specifically:
22
+
23
+
- Devs/agents create bump files as part of their PRs (using `bumpy add` or manually)
24
+
- A pre-push git hook can enforce bump files exist for changed packages
25
+
- In CI, a workflow checks PRs for bump files, leaves a comment on the PR detailing changed packages
26
+
- As PRs merge to the base branch, a "release PR" is kept up to date
27
+
- Shows what packages will be released and their changelogs
28
+
— Including packages bumped automatically due to dependency relationships
29
+
- When release PR is merged, publishing is triggered
30
+
- Oending bump files are deleted and packages are published with updated versions and changelogs
31
+
32
+
All of this is automated via two simple GitHub Actions workflows (see [CI setup](#ci--github-actions) below). You can also run everything locally with `bumpy status`, `bumpy version`, and `bumpy publish`.
22
33
23
34
### Example bump file
24
35
@@ -34,18 +45,10 @@ Added user language preference to the core config.
34
45
Fixed locale fallback logic in utils.
35
46
```
36
47
37
-
The typical CI driven workflow is:
38
-
39
-
1.**`bumpy add`** — developers create bump files as part of their PRs
40
-
2.**`bumpy ci check`** — CI comments on each PR with a release plan preview
41
-
3.**`bumpy ci release`** — on merge to main, CI opens a "Version Packages" PR that bumps versions and updates changelogs. When that PR is merged, it publishes packages.
42
-
43
-
All of this is automated via two simple GitHub Actions workflows (see [CI setup](#ci--github-actions) below). You can also run everything locally with `bumpy status`, `bumpy version`, and `bumpy publish`.
44
-
45
48
## Features
46
49
47
50
-**All package managers** — npm, pnpm, yarn, and bun workspaces
48
-
-**Smart dependency propagation** — configurable rules for how version bumps cascade through your dependency graph (see [version propagation docs](docs/version-propagation.md))
51
+
-**Smart dependency propagation** — configurable rules for how version bumps cascade through your dependency graph (see [version propagation docs](https://github.com/dmno-dev/bumpy/blob/main/docs/version-propagation.md))
49
52
-**Pack-then-publish** — by default, publishes to npm (resolving `workspace:` and `catalog:` protocols, with OIDC/provenance support). Per-package custom publish commands let you target anything — VSCode extensions, Docker images, JSR, private registries, etc.
50
53
-**Flexible package management** — include/exclude any package individually via per-package config, glob patterns, or `privatePackages` setting
51
54
-**Non-interactive CLI** — `bumpy add` works fully non-interactively for CI/CD and AI-assisted development
@@ -60,25 +63,27 @@ All of this is automated via two simple GitHub Actions workflows (see [CI setup]
60
63
# Install
61
64
bun add -d @varlock/bumpy # or npm/pnpm/yarn
62
65
63
-
# Initialize (creates .bumpy/ config directory)
64
-
bumpy init
66
+
# Initialize (creates .bumpy/ directory and config, migrates from changesets if applicable)
67
+
bunx bumpy init
65
68
66
69
# Create a bump file
67
-
bumpy add
70
+
bunx bumpy add
68
71
69
72
# Preview the release plan
70
-
bumpy status
73
+
bunx bumpy status
71
74
```
72
75
73
76
Then set up CI to automate versioning and publishing (see below).
74
77
75
78
## CI / GitHub Actions
76
79
77
-
No separate action to install — just call `bumpy ci` directly in your workflows. Two commands handle the entire release lifecycle:
80
+
No separate action to rely on — just call `bumpy ci` directly in your workflows. Two commands handle the entire release lifecycle:
78
81
79
82
-**`bumpy ci check`** — runs on every PR. Computes the release plan from pending bump files and posts/updates a comment on the PR showing what versions would be released. Warns if any changed packages are missing bump files.
80
83
-**`bumpy ci release`** — runs on push to main. If pending bump files exist, it opens (or updates) a "Version Packages" PR that applies all version bumps and changelog updates. If the current push _is_ the Version Packages PR being merged, it publishes the new versions, creates git tags, and creates GitHub releases.
81
84
85
+
_examples use bun, but works with Node.js_
86
+
82
87
### PR check workflow
83
88
84
89
```yaml
@@ -98,6 +103,7 @@ jobs:
98
103
- run: bunx @varlock/bumpy ci check
99
104
env:
100
105
GH_TOKEN: ${{ github.token }}
106
+
BUMPY_GH_TOKEN: ${{ secrets.BUMPY_GH_TOKEN }} # additional PAT (optional)
101
107
```
102
108
103
109
### Release workflow
@@ -128,6 +134,7 @@ jobs:
128
134
- run: bunx @varlock/bumpy ci release
129
135
env:
130
136
GH_TOKEN: ${{ github.token }}
137
+
BUMPY_GH_TOKEN: ${{ secrets.BUMPY_GH_TOKEN }} # additonal PAT, needed to trigger CI checks on release PR
131
138
```
132
139
133
140
> **Trusted publishing setup:** Configure each package on [npmjs.com](https://docs.npmjs.com/trusted-publishers/) → Package Settings → Trusted Publishers → GitHub Actions. Specify your org/user, repo, and the workflow filename (`bumpy-release.yml`). No `NPM_TOKEN` secret needed. Requires npm >= 11.5.1 — bumpy will warn if your version is too old.
@@ -157,6 +164,7 @@ jobs:
157
164
- run: bunx @varlock/bumpy ci release
158
165
env:
159
166
GH_TOKEN: ${{ github.token }}
167
+
BUMPY_GH_TOKEN: ${{ secrets.BUMPY_GH_TOKEN }}
160
168
NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
161
169
```
162
170
@@ -166,7 +174,7 @@ You can also use `bumpy ci release --auto-publish` to version + publish directly
166
174
167
175
### Token setup
168
176
169
-
The default `github.token` works for basic functionality, but GitHub's anti-recursion guard means PRs created by the default token won't trigger other workflows — so your regular CI (tests, linting, etc.) won't run automatically on the Version Packages PR. To fix this, provide a `BUMPY_GH_TOKEN` secret using either a **fine-grained PAT** or a **GitHub App token**. See the [full token setup guide](docs/github-actions.md#token-setup) for details.
177
+
The default `github.token` works for basic functionality, but GitHub's anti-recursion guard means PRs created by the default token won't trigger other workflows — so your regular CI (tests, linting, etc.) won't run automatically on the Version Packages PR. To fix this, provide a `BUMPY_GH_TOKEN` secret using either a **fine-grained PAT** or a **GitHub App token**. See the [full token setup guide](https://github.com/dmno-dev/bumpy/blob/main/docs/github-actions.md#token-setup) for details.
170
178
171
179
Run `bumpy ci setup` for interactive guidance, or set it up manually:
172
180
@@ -206,22 +214,21 @@ The skill teaches the AI to examine git changes, identify affected packages, cho
206
214
207
215
## Documentation
208
216
209
-
- [Bump file format](docs/bump-files.md) — syntax, bump levels, cascade control
210
-
- [Configuration reference](docs/configuration.md) — all `.bumpy/_config.json` and per-package options
211
-
- [CLI reference](docs/cli.md) — every command with flags and examples
- [Version propagation](https://github.com/dmno-dev/bumpy/blob/main/docs/version-propagation.md) — how dependency bumps cascade through your graph
215
222
216
223
## Why files instead of conventional commits?
217
224
218
225
Tools like semantic-release infer version bumps from commit messages (`feat:` → minor, `fix:` → patch). This works for simple projects but breaks down in monorepos — a single PR often touches multiple packages with different bump levels, squash merges lose per-commit metadata, and commit messages are a poor place to write user-facing changelog entries. Bump files are explicit, reviewable in the PR diff, and can describe changes in language meant for consumers rather than developers. If you prefer commit-based workflows, `bumpy generate` can bridge the gap by auto-creating bump files from your branch commits — it works with any commit style, not just conventional commits.
219
226
220
227
## Why not just use changesets?
221
228
222
-
Bumpy is built as a successor to [@changesets/changesets](https://github.com/changesets/changesets). Changesets is mature and widely adopted, but has stagnated — hundreds of open issues around core design problems that are unlikely to be fixed without a rewrite. See [differences from changesets](docs/differences-from-changesets.md) for a detailed comparison with links to specific issues. The biggest pain points bumpy addresses:
229
+
Bumpy is built as a successor to [@changesets/changesets](https://github.com/changesets/changesets). Changesets is mature and widely adopted, but has stagnated — hundreds of open issues around core design problems that are unlikely to be fixed without a rewrite. See [differences from changesets](https://github.com/dmno-dev/bumpy/blob/main/docs/differences-from-changesets.md) for a detailed comparison with links to specific issues. The biggest pain points bumpy addresses:
223
230
224
-
- **Sane dependency propagation** — changesets hardcodes aggressive behavior where a minor bump triggers a major bump on all peer dependents. Bumpy uses a [three-phase algorithm](docs/version-propagation.md) with sensible defaults and full configurability.
231
+
- **Sane dependency propagation** — changesets hardcodes aggressive behavior where a minor bump triggers a major bump on all peer dependents. Bumpy uses a [three-phase algorithm](https://github.com/dmno-dev/bumpy/blob/main/docs/version-propagation.md) with sensible defaults and full configurability.
225
232
- **Workspace protocol resolution** — changesets uses `npm publish` even in pnpm/yarn workspaces, so `workspace:^` and `catalog:` protocols are NOT resolved, resulting in broken published packages.
226
233
- **Custom publish commands** — changesets is hardcoded to `npm publish`. Bumpy supports per-package custom publish for VSCode extensions, Docker images, JSR, etc.
227
234
- **Flexible package management** — changesets treats all private packages the same. Bumpy lets you include/exclude any package individually.
@@ -231,14 +238,19 @@ Bumpy is built as a successor to [@changesets/changesets](https://github.com/cha
231
238
## Development
232
239
233
240
```bash
234
-
bun install
235
-
bun test
236
-
bun src/cli.ts --help
241
+
bun install # install deps
242
+
bun test # run tests
243
+
bun run build # build CLI
244
+
bunx bumpy --help # invoke built cli
237
245
```
238
246
239
247
## Roadmap
240
248
241
-
- Prerelease mode (for now, use [pkg.pr.new](https://github.com/stackblitz-labs/pkg.pr.new) for preview packages)
242
-
- Bun standalone binary for use outside of JS projects
249
+
- Prerelease mode (for now, use [pkg.pr.new](https://github.com/stackblitz-labs/pkg.pr.new) for branch preview packages)
250
+
- Standalone binary for use outside of JS projects
243
251
- Better support for versioning non-JS packages and usage without package.json files
252
+
- Plugin system for different publish targets, and support multiple targets per package
Copy file name to clipboardExpand all lines: docs/bump-files.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,6 +20,8 @@ Added user language preference to the core config.
20
20
Fixed locale fallback logic in utils.
21
21
```
22
22
23
+
> **Tip:** The description body is optional. If left blank, the bump file still contributes to the release plan (triggering version bumps and dependency propagation), but no entry will appear in the changelog for it.
0 commit comments