ln-32-dependency-upgrader

Upgrade in small batches ordered by prerequisite: runtime and package manager first, then build tooling, frameworks, and leaf packages. Run install, build, lint, and tests after each batch, and revert only the failed batch while keeping verified ones.

Read the official release notes and migration guides for the exact version transition, then search your codebase for affected imports, APIs, configuration, and plugins. A breaking-change claim requires release evidence matching the specific versions involved.

Yes, the workflow detects all package managers, manifests, lockfiles, and workspace files first, then uses each manager's native outdated, audit, and update commands. Lockfiles are only modified by the native package manager, never hand-edited.

Each finding requires the affected version, advisory, reachability context, and a credible remediation. After each batch, the security audit is re-run to distinguish fixed, remaining, newly introduced, and unreachable advisories.

The entire failed batch is reverted without touching user work, the blocking package is recorded, and independent safe batches continue. The final report classifies each batch as KEPT, REVERTED, or SKIPPED with reasons.

Keep routine batches small enough to attribute failure to a specific package. Only batch framework families, analyzers, or tightly constrained peers together when their compatibility matrix requires it.