Dependency Risk Scanner: Spotting Packages That Will Hurt to Upgrade

The Dependency Risk Scanner classifies the dependencies in your project by how likely they are to cause pain during an upgrade. It runs as part of a normal scan and contributes to your DriftScore. This article is for developers triaging a scan and for leaders who want to understand where upgrade risk concentrates.

What it detects

The scanner reads your manifests and lockfiles and classifies packages into risk categories, including:

• Deprecated packages — dependencies that maintainers have marked as no longer supported, or that have a known successor.
• Native modules — packages with compiled native bindings (for example node-gyp style builds) that can break across Node, OS, or architecture changes.
• Platform-specific dependencies — packages that only work on certain operating systems or CPU architectures, which create portability and CI risk.

Each finding identifies the package and the reason it was flagged, so you can decide whether to keep, replace, or pin it.

Why it matters

Deprecated packages accumulate quietly. They keep working until a transitive security advisory or a major framework bump forces the issue, and by then the migration is urgent rather than planned. Native modules are the most common cause of "works on my machine" failures and of CI breakage when a runtime version moves. Platform-specific dependencies turn an innocent upgrade into a cross-platform debugging session.

The scanner surfaces these before you upgrade, so the risk is visible in your DriftScore and reviewable in a pull request instead of discovered at deploy time.

How to act

Run a scan in the project root:

vg

Review the dependency risk findings in the output. For deprecated packages, plan a migration to the recommended successor and capture it in your backlog. For native modules, confirm they build cleanly across every runtime and OS your CI matrix targets. For platform-specific packages, make sure your CI exercises the platforms you ship to.

To capture today's risk as a reference point and gate future regressions, create a baseline:

vg baseline

Then fail CI when risk worsens against that baseline:

vg scan --baseline .vibgrate/baseline.json

Triage tips

• Treat deprecated direct dependencies as higher priority than deprecated transitive ones — you control direct ones.
• For native modules, prefer pure-JS or prebuilt-binary alternatives when an equivalent exists.
• Pin platform-specific packages and document the supported platforms so reviewers understand the constraint.

Related

Dependency Risk works alongside the Dependency Graph Scanner (duplicate and phantom packages) and the Breaking Change Exposure Scanner. See the Extended Scanners Overview, the DriftScore explainer, and Drift Baselines for the gating workflow.