Prove the dependency tree you actually changed

Diff the resolved tree

A manifest may show one direct package moving from one range to another while the lockfile changes dozens of transitive packages. Review both. npm documents that package-lock.json records the exact generated tree and is intended for source control, reproducible installs, and readable dependency diffs. Equivalent mechanisms differ by ecosystem, but the evidence question is constant: which exact components will the build now consume?

Ask the agent for the old and new direct version, every added or removed transitive dependency, and the reason each manifest or lockfile changed. Reject lockfile regeneration that also upgrades unrelated packages unless the package manager makes that unavoidable and the broader scope is reviewed. A clean textual diff is not enough if platform-specific resolution happens only in CI.

npm package-lock documentation ↗

Read the producer's change record

Check official release notes, migration guides, supported runtime versions, and security advisories for every crossed major version. Search the repository for removed APIs and configuration names before installing. An agent summary is a navigation aid, not the source of truth. Preserve links to the exact upstream material and distinguish confirmed breaking changes from likely effects inferred from local use.

For a hypothetical HTTP client upgrade, evidence might include a changed timeout default, a removed constructor option, and a new transitive TLS library. The local plan would identify each call site, run contract tests against a controlled server, and inspect connection behavior. This example is not a claim that such an upgrade was performed.

Check security without outsourcing judgment

GitHub's dependency review can display direct and indirect changes and flag known vulnerabilities or license policy issues in supported ecosystems. npm audit can report advisories, and its signature mode can verify registry signatures and available provenance attestations. These are useful signals with boundaries: an absent advisory does not prove safe code, and npm explicitly says provenance links an artifact to source and build instructions but does not guarantee the package contains no malicious code.

Inspect new lifecycle scripts, requested permissions, native binaries, network behavior, maintainership changes, and license terms according to project risk. Record scanner configuration and database time, because results can change after the review.

GitHub dependency review ↗

npm provenance limitations ↗

Make rollback an artifact decision

Keep the previous lockfile and release artifact addressable. Build the candidate from a clean checkout with the project's pinned package-manager version, then run focused compatibility checks plus the normal build and test gates. Compare bundle size, startup behavior, generated files, and runtime warnings where relevant. State which platforms were not exercised.

The handoff should contain the dependency-tree diff, upstream reasons, checks actually run, scanner output, unresolved advisories, and the previous known-good artifact or commit. If reverting the package also requires reverting generated code or a data migration, the change is not a simple dependency rollback and should be planned as a release transition. Include the owner and review date for any accepted advisory or license exception so temporary risk does not silently become permanent policy.