dependency-upgrader

name	dependency-upgrader
description	Upgrade dependencies for Java/Kotlin (Gradle/Maven) and TypeScript/Node projects with minimal risk: plan the bump, apply changes incrementally, run tests/builds, and document breaking changes. Use when the user asks to bump deps, update frameworks, or address CVEs.

Dependency upgrader

Goal

Safely upgrade dependencies with minimal, reviewable diffs and clear verification.

Inputs to ask for (if missing)

• Which ecosystem: Gradle/Maven, Node/TypeScript, or both.
• Scope: one dependency, a set (e.g., Spring Boot), or "everything".
• Constraints: patch/minor only vs allow majors; time budget; CI requirements.
• Motivation: CVE fix, feature need, or routine maintenance.
• Can the agent use web search to confirm latest versions and read migration notes? (If not, rely on registry lookups.)

Workflow (checklist)

1. Detect the project type and package manager
   • Node: package.json + lock file (pnpm-lock.yaml, package-lock.json, yarn.lock, bun.lock).
   • Gradle: gradlew, build.gradle(.kts), settings.gradle(.kts), gradle/libs.versions.toml.
   • Maven: pom.xml.
   • If the required package manager or build tool is missing (npm/pnpm/yarn/bun, Gradle, Maven), tell the user and ask whether to install it or proceed with a manual edit-only upgrade.
2. Establish a baseline
   • Record current versions (dependency file + lock files).
   • Run the smallest reliable test/build command the repo uses (then expand if needed).
3. Plan the upgrade
   • Prefer the smallest bump that solves the problem.
   • Choose target versions using up-to-date sources:
     • Use web search (if available) to confirm latest stable versions and skim official release notes/migration guides.
     • Cross-check with the registry/source of truth (npm registry, Maven Central, Gradle Plugin Portal).
   • Group by risk:
     • low: patches/minors, leaf deps
     • medium: build tools/plugins
     • high: framework majors (Spring Boot), runtime bumps (Java/Node)
   • For majors: skim upstream migration notes and list expected breakpoints before editing.
4. Apply upgrades incrementally
   • Update one group at a time; keep diffs focused.
   • After each group: run tests/build and fix breakages immediately.
   • Use the playbooks in references/ for ecosystem-specific commands.
5. Validate and document
   • Run the repo's "CI equivalent" commands (tests + build).
   • Document:
     • what changed (versions)
     • why (CVE, compatibility, feature)
     • notable migrations or breaking changes
     • any follow-ups (deprecations, future majors)

Deliverable

Provide:

• The list of version bumps (old -> new).
• The commands run and their result (tests/build).
• Any breaking changes and required code/config migrations.