Your DriftScore moves as your project and the ecosystem change. Knowing which factors push it up — and which actions bring it down — lets you spend upgrade effort where it pays off. This article maps the contributors for developers and tech leads alike.
Overview
Vibgrate derives the DriftScore from many signals collected during a scan. Run one from your project root to see the breakdown:
vg
What pushes the score up
- Dependencies falling behind — the further a direct or transitive dependency is from its current release, the more it contributes. Major-version gaps weigh more than patch gaps.
- End-of-life runtimes — a language or platform version past its support window is a strong upward driver.
- Deprecations — packages or APIs maintainers have marked as going away.
- Breaking-change exposure — use of packages and patterns known to cause upgrade pain.
- Time — drift grows even when you do nothing, because upstream keeps releasing.
What brings the score down
- Upgrading the heaviest contributors first — the report ranks what's pushing the score up; start there.
- Moving off end-of-life runtimes — often the single biggest reduction.
- Replacing deprecated packages — removes both the deprecation signal and future breakage.
- Routine, small upgrades — keeping pace prevents large gaps from forming.
Prioritizing with the report
vg report
The report turns the breakdown into a prioritized, human-readable view. Tackle the few items with the largest weight rather than upgrading everything at once.
Why the score can rise without code changes
Because drift is relative to the ecosystem, a score can climb between scans even if you changed nothing — a new major shipped upstream, or a runtime crossed its end-of-life date. This is expected and is exactly why periodic scanning matters.
Related
- See How to interpret DriftScore for the 0-100 bands.
- See End-of-life runtimes and Deprecations and breaking changes for two of the biggest drivers.
- See Transitive vs direct dependencies to understand which gaps you control directly.