dependency-upgrader

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Dependency upgrader

依赖升级器

Goal

目标

Safely upgrade dependencies with minimal, reviewable diffs and clear verification.
安全升级依赖,生成最小化、可审核的diff以及清晰的验证结果。

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.)
  • 所属生态:Gradle/Maven、Node/TypeScript,或两者皆有。
  • 升级范围:单个依赖、一组依赖(例如Spring Boot),或「所有依赖」。
  • 约束条件:仅允许补丁/次版本升级 vs 允许主版本升级;时间预算;CI要求。
  • 升级动机:修复CVE、功能需求,或日常维护。
  • Agent是否可以使用网页搜索来确认最新版本、阅读迁移说明?(若不允许,则依赖注册中心查询结果。)

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)
  1. 检测项目类型和包管理器
    • Node:
      package.json
      + 锁文件(
      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
    • 若缺失所需的包管理器或构建工具(npm/pnpm/yarn/bun、Gradle、Maven),告知用户并询问是安装该工具,还是仅进行手动编辑式升级。
  2. 建立基线
    • 记录当前版本(依赖文件 + 锁文件)。
    • 运行代码库使用的最小可靠测试/构建命令(必要时可扩展范围)。
  3. 规划升级方案
    • 优先选择能解决问题的最小版本跨度。
    • 使用最新来源选择目标版本:
      • 若允许网页搜索,通过搜索确认最新稳定版本,浏览官方发布说明/迁移指南。
      • 与注册中心/权威来源交叉校验(npm registry、Maven Central、Gradle Plugin Portal)。
    • 按风险分组:
      • 低风险:补丁/次版本升级、叶子依赖
      • 中风险:构建工具/插件
      • 高风险:框架主版本升级(Spring Boot)、runtime 版本升级(Java/Node)
    • 针对主版本升级:编辑代码前先浏览上游迁移说明,列出预期的断点。
  4. 增量应用升级
    • 每次仅更新一组依赖,保持diff聚焦。
    • 每更新完一组后:运行测试/构建,立即修复出现的问题。
    • 使用
      references/
      下的操作手册执行对应生态的专属命令。
  5. 验证与记录
    • 运行代码库的「等价CI」命令(测试 + 构建)。
    • 记录以下内容:
      • 变更内容(版本号)
      • 升级原因(CVE、兼容性、功能)
      • 值得注意的迁移项或破坏性变更
      • 后续待办项(废弃提示、未来主版本升级计划)

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.
提供以下内容:
  • 版本升级列表(旧版本 -> 新版本)。
  • 运行过的命令及其结果(测试/构建)。
  • 所有破坏性变更,以及所需的代码/配置迁移内容。