@varlock/bumpy v1.15.0

• #120 (minor)
  Change detection is now package.json-field-aware: when package.json is the only changed file in a package, bumpy diffs it against the base branch and only requires a bump file if a publish-affecting field changed. The new ignoredPackageJsonFields option (default ["devDependencies"]) controls which fields are ignored, so a dev-only dependency bump (e.g. Dependabot) no longer requires a bump file — unless the changed dep matches the package's releaseTriggeringDevDeps.

  ci check no longer posts a "you're good to go" comment while exiting 1. When the check fails because changed packages have no bump file, the comment now matches the failing status, lists the uncovered packages, and points at an empty bump file (bumpy add --empty) to acknowledge an intentional no-release.

  Add a per-package releaseTriggeringDevDeps option: names/globs of devDependencies that affect a package's published output (most often because they're bundled in). A change to one requires a release, and a listed internal workspace dep's own releases cascade with a patch bump — shorthand for a cascadeFrom rule of { trigger: 'patch', bumpAs: 'patch' }.

• #122 (patch)
  Changelog entries now use a block layout when a summary is multi-line, long (>120 chars), or contains markdown block syntax (headings, lists, blockquotes, code fences, tables). In those cases the entry metadata (*(type)*, PR link, "Thanks @user!") goes on its own line and the summary is rendered indented below it, instead of being jammed onto the same line. Short single-line summaries are unchanged and stay inline. Internal blank lines in a summary are now preserved so markdown paragraphs and lists render correctly. Applies to both the default and github formatters.

• #124 (patch)
  Label and link npm targets published to GitHub Packages correctly. Packages publishing to a GitHub Packages registry (npm.pkg.github.com) were labelled npm in the GitHub release notes and bumpy status/bumpy ci plan output, with a "Published to" badge linking to a non-existent npmjs.com page (404). The configured registry is now honoured: such targets are labelled GitHub Packages and link to the package page under the repo (https://github.com/<owner>/<repo>/pkgs/npm/<name>), resolving the repo from the package's repository field or GITHUB_REPOSITORY. Other custom/private registries no longer emit a dead npmjs.com link. buildPublishUrl now honours its registry argument (previously the unused _registry param).

• #125 (patch)
  Fix changed-package detection in single-package (non-monorepo) repos. Both findChangedPackages (used by check/ci check) and mapFilesToPackages (used by generate) matched changed files against pkgRelDir + '/', but for the root package the relative dir is empty, so the check became file.startsWith('/') — always false for git's relative paths. As a result ci check always reported "No managed packages have changed" (never requiring a bump file or posting a PR comment) and generate never attributed commits to the root package. The root package (empty relative dir) now treats every changed file as belonging to it, while still honoring changedFilePatterns.

• #118 (patch)
  Stream buildCommand/publishCommand output live to the parent process and surface the child's real failure reason. Custom publish commands (vsce, ovsx, anything bespoke) previously ran through a buffering runner that discarded stdout and never streamed output, so a failure like an expired marketplace token produced only a generic Command failed wrapper with no usable cause in CI logs. These commands now run through a streaming runner (spawn with piped+teed stdio) that prints output as it happens and includes both stdout and stderr in the thrown error. The capturing runAsync/runArgsAsync helpers (still used for internal git/npm calls whose output is parsed) also now include stdout in their error messages.

Published to

• ✅ npm

@varlock/bumpy v1.14.0

• (minor) - Add prerelease channels — branch-based prerelease lines (e.g. next → @next dist-tag) where prerelease versions are never committed to git. Targets derive from bump files, counters from the registry; shipped bump files are tracked by moving them into .bumpy/<channel>/. Includes channel-aware version / publish / status / ci release flows, exact-pinned lockstep cycle publishes, and promotion-by-merge to stable.
• #115 (patch) - When a prerelease cycle is promoted (channel → main) or graduated (channel → channel), any lingering release PR on the source channel is now closed automatically with an explanatory comment — merging it would have offered another prerelease of a cycle that already moved on.
• #110 (patch) - ci check now reads bump files in channel directories, so promotion PRs (channel → main) and graduation PRs (channel → channel) correctly report the cycle's pending releases instead of failing with "no bump files found". Channel-dir bump files render with their subdir path (next/feature.md) so view/edit links resolve.
• (patch) - Channel release PR titles and bodies now show deterministic versions: targets with a wildcard counter (1.2.0-rc.x) derived purely from committed state, instead of registry-derived counters that could drift between PR creation and publish. Multi-package cycles show a package count in the title instead of an arbitrary lead package. The PR check comment and version output use the same .x wildcard; status / ci plan still show live registry-derived counters (.? when offline).
• #110 (patch) - The PR check comment now explicitly calls out promotion PRs (channel → stable): the headline explains that merging ends the prerelease cycle and ships stable, and bump files that already shipped on a channel are annotated with their dist-tag (e.g. next/feature.md (shipped on @next)).

Published to

• ✅ npm

@varlock/bumpy v1.14.0-rc.1

• #104 (minor) - Add prerelease channels — branch-based prerelease lines (e.g. next → @next dist-tag) where prerelease versions are never committed to git. Targets derive from bump files, counters from the registry; shipped bump files are tracked by moving them into .bumpy/<channel>/. Includes channel-aware version / publish / status / ci release flows, exact-pinned lockstep cycle publishes, and promotion-by-merge to stable.
• #107 (patch) - Channel release PR titles and bodies now show deterministic versions: targets with a wildcard counter (1.2.0-rc.x) derived purely from committed state, instead of registry-derived counters that could drift between PR creation and publish. Multi-package cycles show a package count in the title instead of an arbitrary lead package. The PR check comment and version output use the same .x wildcard; status / ci plan still show live registry-derived counters (.? when offline).

Published to

• ✅ npm

@varlock/bumpy v1.14.0-rc.0

• #104 (minor) - Add prerelease channels — branch-based prerelease lines (e.g. next → @next dist-tag) where prerelease versions are never committed to git. Targets derive from bump files, counters from the registry; shipped bump files are tracked by moving them into .bumpy/<channel>/. Includes channel-aware version / publish / status / ci release flows, exact-pinned lockstep cycle publishes, and promotion-by-merge to stable.

Published to

• ✅ npm

@varlock/bumpy v1.13.2

• #101 (patch) - Harden the publish flow for two failure modes hit when releasing brand-new packages via GitHub Actions + npm trusted publishing (OIDC).
  • Detect the new-package case before any side effects. When OIDC is the only available auth path (no NPM_TOKEN/NODE_AUTH_TOKEN, no .npmrc auth), bumpy now checks the npm registry up front and emits a clear error directing the user to publish a 0.0.0 placeholder before merging — instead of failing partway through with stranded GitHub draft releases and remote tags. The check is skipped when a token fallback is present, so users who enable id-token: write for provenance attestations alongside token auth are unaffected.
  • Replace blanket git push --tags after publish with per-tag force push. gh release create --draft --target SHA creates the tag on the remote at draft-creation time; if a prior publish failed and HEAD has since moved, the remote tag is stale and git push --tags rejects with "already exists". The new logic iterates releasePlan.releases minus failed packages and force-pushes each tag individually, preserving the anySucceeded-aware semantics already used for local tag movement — packages whose targets all succeeded in a prior run are stripped upstream and their tags stay at the SHA the artifact was actually published from.

Published to

• ✅ npm

@varlock/bumpy v1.13.1

• #99 (patch) - Fix scrolling in bumpy add when there are many packages. The interactive bump-select prompt now renders a viewport that fits within the terminal, scrolling the package list (with ▲ N more / ▼ N more indicators) as the cursor moves. Previously, when the list exceeded terminal height, navigating up would snap the cursor back to the bottom because the redraw cursor-up lost its anchor once content scrolled off-screen. Closes #96.

Published to

• ✅ npm

@varlock/bumpy v1.13.0

• #97 (minor) - Recommend pull_request_target for the bumpy ci check workflow so fork PRs receive release-plan comments. Previously, fork PRs running under pull_request got a read-only token, so the check would fail red with no helpful comment — a bad first impression for OSS projects. bumpy ci check now recognizes the pull_request_target event when reading the PR number from GITHUB_EVENT_PATH, and emits a clearer warning that links to the new docs when comment posting fails on a fork PR. See the updated GitHub Actions docs for the new workflow (the version is resolved from the base branch's package.json, so no version pinning duplication).

Published to

• ✅ npm

@varlock/bumpy v1.12.0

• #94 (minor) - Detect catalog entry changes as package changes. When a catalog version in pnpm-workspace.yaml (pnpm) or root package.json (bun/yarn catalog/catalogs, plus workspaces.catalog/workspaces.catalogs) is modified, bumpy add and bumpy check now flag every package that references the changed entry via catalog: / catalog:<name> as changed. Closes #92.

Published to

• ✅ npm

@varlock/bumpy v1.11.0

• #91 (minor) - Add --expect-mode flag to bumpy ci release for asserting the detected release mode (version-pr or publish). Enables split-job release workflows where each job fails loudly if the runtime state doesn't match what the job expects. Refactored ReleaseOptions to rename the existing mode field to autoPublish: boolean and add assertMode. --expect-mode and --auto-publish cannot be combined.

Published to

• ✅ npm

@varlock/bumpy v1.10.2

• #89 (patch) - Always show bump type label on each changelog item instead of only when it differs from the release type

Published to

• ✅ npm