Supply chain dependency reviews
Upgrade a foundational library in reviewable steps
Large dependency jumps mix compatibility changes with security work. Map the affected behaviours and keep each released artifact traceable during the transition.
In this article
Identify the application's actual dependency surface
List the library features the application uses, including configuration, error types, plugins and build integration. Read the official migration notes for the exact source and target versions.
Inspect transitive changes and runtime requirements. A framework update can also replace bundler, parser or server components that deserve their own compatibility checks.
Separate required security fixes from optional feature adoption where practical. This keeps the release's purpose clear without postponing necessary remediation indefinitely.
Build fixtures around fragile contracts
Choose representative workflows and known edge cases before editing imports or configuration. Include server rendering, authentication, uploads or other boundaries relevant to the library.
Run the old and candidate versions against those fixtures and review output differences. Do not accept a large snapshot rewrite without understanding which behaviour changed.
Keep a record of removed compatibility shims. Some may no longer be needed, while others encode application requirements not covered by the library's defaults.
Stage the release by artifact
Use a bounded rollout with the exact reviewed build. Monitor both technical failures and business workflow outcomes.
Retain the previous approved artifact and any configuration it requires. If the upgrade changes persistent data or generated assets, define whether the old version can still operate before calling rollback safe.
For an illustrative server-library migration, a new serialisation format may be accepted by new clients but not old open tabs. Maintain a compatible response contract during the transition or provide a controlled upgrade path.
Retire old dependencies deliberately
Remove obsolete packages and verify the resolved graph after the migration. A compatibility package left behind can retain the vulnerable transitive dependency the upgrade was meant to remove.
Update build inventory, provenance and operating notes. Confirm the deployed artifact rather than relying only on the repository state.
Close temporary exceptions with evidence or renew them through the responsible owner. The migration should reduce uncertainty about the software the business runs, not merely produce a newer version label.
Primary sources
GitHub: dependency reviewSLSA: provenanceReferences checked 11 September 2026.