⬆️

Dependency Updater

Verified

by Community

Inspects your project's `package.json` or `requirements.txt`, finds outdated packages, fetches each one's changelog, and produces a prioritized upgrade plan that distinguishes safe patches from breaking-major upgrades. Recommends the order to apply them.

dependenciesnpmpipyarncargoupgrademaintenancepackage

Dependency Updater

Produce a safe, prioritized upgrade plan for project dependencies.

Workflow

  1. 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.

  1. Run the command and parse the output.
  2. 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.

  1. For MAJOR upgrades, fetch the changelog (curl to GitHub releases API or the package page) and extract breaking changes.
  2. 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.