Polyrepo
An interactive CLI for managing a folder of local npm package repos on GitHub and GitLab: version bumps through a PR/MR, npm publishing, releases, and cross-package dependency drift — all from one tool.
When you'd reach for this
One package is a git clone and an npm publish. Fifteen packages in one folder turns into a discipline problem: which branch is named what where, what hasn't been pushed, who forgot to run tests before a release. polyrepo-cli takes that process off your hands.
Releasing each package is the same manual loop
Go into the directory, bump the version, open a PR, wait for the merge, tag it — then repeat for the next package. A checkbox picks which packages need it, and the whole cycle runs for all of them at once.
One repo's default branch is master, another's is main
A script with a hardcoded branch name breaks exactly where someone renamed the default branch on the host. The actual name is detected per repository, and everything else works the same regardless of what it's called — or whether the repo is on GitHub or GitLab.
An npm publish run stalls halfway through the list
The login expired, and that only comes to light once the fifth package out of ten is already packed and ready to publish. Authentication is checked — and refreshed if needed — once, before publishing even starts.
Dozens of releases later, the repos are full of debris
Branches from merged PRs/MRs stick around both locally and in the remote-tracking list, and references to branches long deleted on the host don't disappear on their own. A periodic check finds all of it and offers to clean it up safely.
One of the repos is itself a pnpm monorepo with several packages
A folder of package repos doesn't always mean exactly one package per repo — sometimes a single repo holds several publishable packages, each with its own version. That kind of repo is detected on its own, and each package inside it gets versioned, tagged, and published independently, with no manual setup needed.
At a glance
Setup and repo discovery
The list of package folders lives in a config file — no hand-editing JSON. A separate command diffs a GitHub org's (or GitLab group's) repos against what's already cloned locally and pulls down what's missing.
Status for every package at a glance
Local version, branch, git status, the version on origin, tag, release, and npm registry version for every package — checked in parallel. Outdated dependencies, vulnerabilities, and open PRs/MRs are aggregated across every repo at once, with export to Markdown, JSON, CSV, or HTML.
Health checks with safe self-repair
Checks the environment, whether a repo's default branch has drifted from its host, divergence from origin, branch protection, and leftover branches from past releases — fixing what's safe to fix automatically.
Branch syncing without surprises
Selected repos fast-forward to their up-to-date default branch — whatever it's actually named, master or main. A full reset of a dirty repo is only ever available behind an explicit flag, never by default.
A guided release workflow
The version bumps through a branch and PR/MR — a plain bump, a prerelease, or an exact version — resuming exactly where a previous run left off, drafting a CHANGELOG.md entry from the commit history on its own. Multiple packages in the same repo each get their own tag that never collides, even when their version numbers match. Separate steps close out the process with a tag and a release.
Publish, and run anything
Only packages actually ahead of the registry get published to npm — private packages and a monorepo's own workspace root are never offered — and an expired login is handled on its own. Any command runs across selected packages one at a time, with live terminal output.
Web interface
polyrepo ui opens a local web interface: one table of every package with the problems called out and monorepos as colored blocks, a form for every command, live reports and logs of each run. After every outcome it suggests what to do next. The server listens on 127.0.0.1 only, behind a one-time token.
