release:patch and publish:patch both ran:
bumpx patch --recursive --yesThat bumps the version in package.json and stops. The Releaser workflow triggers on v* tag pushes, so with no commit, no tag and no push, the release never fires — bun run release:patch leaves a dirty working tree and publishes nothing.
- "release:patch": "bun x --bun @stacksjs/bumpx patch --recursive --yes",
- "publish:patch": "bun x --bun @stacksjs/bumpx patch --recursive --yes",
+ "release:patch": "bun x --bun @stacksjs/bumpx patch --recursive --commit --tag --push --yes",
+ "publish:patch": "bun x --bun @stacksjs/bumpx patch --recursive --commit --tag --push --yes",How this surfaced
Releasing v0.2.26 (the @buddysh/buddy rename, #966). The script did not produce a release, so the flags had to be spelled out by hand.
The history suggests that has been the pattern for a while — every release is a chore: release vX.Y.Z commit plus a matching tag, which is exactly what --commit --tag --push produces and what the script alone cannot. So the flags appear to have been supplied manually each time rather than by the script.
The added flags are the same ones bun-query-builder's release:patch uses, and the same invocation that produced v0.2.26 here — so this is the working command being written down, not a new approach.
Two things left alone, for you to decide
publish:patchis now byte-identical torelease:patch. I fixed both rather than guess at the intended difference, but one of them is probably redundant — either drop it, or make itbun run release:patch.- There are no
release:minor/release:majorscripts.bun-query-builderhas both. Happy to add them for parity if you want; it seemed out of scope for a bug fix.
Verification
package.json parses, pickier clean, and the diff is the two script lines only.
I deliberately did not execute the fixed scripts — they commit, tag, push and publish. The flags are verified by the fact that this exact invocation produced v0.2.26 here and v0.3.4 in bun-query-builder.
🤖 Generated with Claude Code