Dependabot Batch

1---
2name: dependabot-batch
3description: Use when a repo has several open Dependabot PRs and you want them collapsed into ONE branch and ONE PR instead of merging them one at a time — "batch the dependabot PRs", "combine all dependency updates", "fix all dependabot suggestions in one branch", "too many dependabot PRs", "our CI/preview deploys are burning money on dependabot". Also use when asked to clear open Dependabot security alerts, or when a dependency-update PR needs verifying before merge. Covers any ecosystem Dependabot supports (npm/pnpm/yarn/bun, pip, cargo, go, bundler, maven, github-actions, docker), and handles the case where some suggested bumps are breaking and must be held back.
4---
5
6# Batching Dependabot PRs
7
8## Why this exists
9
10Dependabot opens one PR per update. Each one triggers a full CI run and, on
11platforms like Vercel or Netlify, a preview deployment. Ten open PRs means ten
12builds for changes that will all end up in the same lockfile anyway — and they
13serialize badly, because every merge invalidates the others' lockfiles and
14forces a rebase.
15
16Collapsing them into a single branch turns N build cycles into one, and gives
17you a single place to verify the combined dependency graph — which is what
18actually ships. Bumps that pass in isolation can still conflict with each other;
19batching surfaces that before merge rather than after.
20
21## The shape of the work
22
23Gather → apply manifest edits by hand → regenerate the lock → run every gate →
24drop only what's genuinely broken → one PR that documents what was held back.
25
26The one thing to internalize: **do not merge or cherry-pick the Dependabot
27branches.** They each rewrote the lockfile against a different base, so combining
28them produces conflicts that are tedious and easy to resolve wrongly. Take only
29the *manifest* version numbers from them and let the package manager rebuild the
30lock once, from a clean state. The lockfile is derived output — regenerate it,
31never hand-merge it.
32
33## 1. Gather everything
34
35```bash
36gh pr list --state open --author "app/dependabot" \
37  --json number,title,headRefName,createdAt --limit 100
38gh api repos/{owner}/{repo}/dependabot/alerts \
39  --jq '.[] | select(.state=="open") | {num:.number, pkg:.dependency.package.name,
40        sev:.security_advisory.severity,
41        vuln:.security_vulnerability.vulnerable_version_range,
42        patched:.security_vulnerability.first_patched_version.identifier}'
43```
44
45Pull alerts too, not just PRs. Alerts on transitive dependencies often have no PR
46at all — they're fixed by an override/resolution/constraint, and folding them in
47here costs nothing extra.
48
49Then read each PR's manifest change (ignore the lockfile half of the diff):
50
51```bash
52gh pr diff <N> -- package.json      # or Cargo.toml, go.mod, requirements.txt…
53```
54
55**Multi-account `gh` gotcha.** If `gh` errors with `Could not resolve to a
56Repository`, the active account can't see this repo. Don't switch the global
57account — that's shared state you'd be mutating out from under the user. Scope a
58token to the command instead:
59
60```bash