Dependency Updater
Produce a safe, prioritized upgrade plan for project dependencies.
Workflow
- Detect the project type:
- package.json present → Node project, use npm outdated --json (or yarn outdated, pnpm outdated).
- requirements.txt or pyproject.toml → Python project, use pip list --outdated --format=json.
- Cargo.toml → Rust, use cargo outdated --format json.
- go.mod → Go, use go list -m -u -json all.
- Run the command and parse the output.
- For each outdated package, classify the gap:
- PATCH (1.2.3 → 1.2.4) → almost always safe.
- MINOR (1.2.x → 1.3.0) → usually safe, scan changelog.
- MAJOR (1.x → 2.x) → potentially breaking, MUST scan changelog and migration guide.
- For MAJOR upgrades, fetch the changelog (
curlto GitHub releases API or the package page) and extract breaking changes. - Group the plan into phases.
Output format
# Dependency Upgrade Plan — <project>
<N> packages outdated. <P> patch, <M> minor, <X> major.
## Phase 1 — Patch upgrades (low risk, batch all)
npm install <pkg1>@<patch> <pkg2>@<patch> ...
- <pkg1>: 1.2.3 → 1.2.4 — bug fixes only
- <pkg2>: 2.4.1 → 2.4.5 — bug fixes
## Phase 2 — Minor upgrades (review changelogs, batch with care)
- <pkg3>: 1.5.0 → 1.7.0
- Changelog: <link>
- Notable: <new API X added; deprecated Y>
- Action: safe to upgrade; consider migrating off Y in a follow-up.
## Phase 3 — Major upgrades (one at a time, plan migration)
- <pkg4>: 2.x → 3.x
- Changelog: <link>
- Breaking changes:
- <Change 1> — affects <files>
- <Change 2>
- Migration guide: <link>
- Action: open a separate PR; update <files X, Y>; expect <test scope>.
## Skipped
- <pkg5>: pinned for compatibility with <reason>
- <pkg6>: blocked by upstream issue <link>
## Suggested order
1. Phase 1 in one PR.
2. Phase 2 grouped by ecosystem (e.g. all React-related minors together).
3. Phase 3 one at a time, with verification after each.
Risk flags
Before recommending any upgrade, flag these:
- Deprecation warnings in current version → upgrade is more urgent.
- Security advisory (
npm audit) → upgrade ASAP, even if breaking. - Lockfile vs declared version mismatch → fix before upgrading.
- Peer dependency conflicts → call out explicitly, may need coordinated upgrades.
Anti-patterns
- Don't auto-run the upgrade. Produce the plan, let the human apply it.
- Don't batch majors. One major upgrade per PR.
- Don't skip the changelog read for majors. "Should be fine" is how you ship a regression.
- Don't bump packages just because they have updates. Patch upgrades are usually safe; minor/major need a reason.
When to NOT update
- Right before a release freeze.
- If the current version has no security or compatibility issues and the team has higher priorities.
- If the upgrade requires migrating off a deprecated API the project depends on heavily — schedule a separate effort.