Reference

Architecture

Every command starts from the same config file (roots/packages) resolved into a flat list of repos. Read-only checks (git status, tag/release/registry/PR lookups) run through a small concurrency-limited parallel map, so a full list or doctor across many repos doesn't wait on one repo at a time. Anything that mutates state — a commit, push, merge, or tag — goes through one shared git/gh/npm execution layer that always prints the command it's about to run and, for mutating steps, respects --dry-run uniformly across every command that has one.

bump is the one command with real cross-run state to track: instead of storing anything itself, it re-derives exactly how far a previous attempt got (branch pushed? PR opened? PR merged?) straight from git/GitHub on every run, which is what makes re-running it after an interruption safe without any local bookkeeping to go stale.

Comparison

Narrower in scope than a monorepo build orchestrator (Nx, Turborepo, Lerna's task-running side) — polyrepo-cli doesn't build a dependency graph or cache task output, because it's built for a folder of independent repos, each with its own package.json and its own GitHub remote, not a single workspace. It also doesn't replace a changelog/versioning tool like Changesets — it drafts a CHANGELOG.md entry as part of bump, but the actual workflow it automates is the git/GitHub/npm mechanics around a release (branch, PR, merge, tag, GitHub Release, npm publish) across many repos at once, not changeset accumulation within one.

Development

git clone https://github.com/macrulezru/polyrepo-cli.git
cd polyrepo-cli
npm install
npm test

Unit tests cover the pure logic that doesn't need a real git/gh/npm — version bumping, CHANGELOG.md entry insertion, cross-package dependency drift detection, and bump-branch-name pattern matching — using real temporary files on disk rather than mocks.

License

MIT — see LICENSE.