Methodology
Every number on a report comes from the rules below. They are deliberately simple, so you can check them yourself.
Versions
With a package-lock.json, the exact installed version is checked. Without one, the lowest published version your range allows is checked (worst case), and those findings are marked “may already be fixed”.
Findings
| Finding | Risk |
|---|---|
| Known vulnerability (OSV.dev) | The advisory's own severity: Critical High Medium Low Without a severity: Critical for a known malicious package, otherwise Medium. |
| Package deprecated by its authors | High |
| Only the version you use is deprecated | Medium |
| No release for more than 2 years | Medium |
| Single npm maintainer | Low Medium if also idle for 2 years |
| 1–2 major versions behind | Low |
| 3 or more major versions behind | Medium |
A package's risk is its worst finding. @types/* packages skip the single-maintainer and major-versions-behind findings: DefinitelyTyped publishes all of them under one account, and their major version follows the runtime or library they describe.
Health score
Start at 100 and subtract per package. devDependencies count half, and the score never goes below 0.
- 85–100
- Healthy
- 60–84
- Needs attention
- Below 60
- At risk
Upgrade plan and estimates
Steps are ordered by risk removed per hour of work. Estimates are rough ranges:
- Patch or minor upgrade
- ~15 min
- Renamed package
- ~30 min
- Major upgrade
- 0.5–1 day, plus 0.5 day per extra major
- Replace a deprecated package
- 0.5–1 day
- Low-risk maintenance finding
- Listed as “monitor”, with no estimate
Data sources
- npm registry
- Versions, deprecation notices, maintainers, release dates
- npm downloads
- Weekly download counts
- OSV.dev
- Known vulnerabilities
- deps.dev
- Source repository and OpenSSF Scorecard
Data is cached for 24 hours.