unmaintained

The problem

Plenty of tools tell you a dependency is out of date. Almost none tell you it is abandoned. And the heuristic everyone reaches for — "no release in a year" — is wrong: a small, finished library can sit untouched for years and be perfectly healthy. Punishing "done" is how you train people to ignore the warning.

unmaintained answers the one question the other tools skip: is anyone still home? It reads your package.json, asks a few public data sources whether each dependency still has a pulse, and reports the ones that do not.

How it works

Two principles shape every verdict. Tiers map to confidence, not severity — and the absence of data is never a guilty verdict. If a package has no GitHub repo or a source is rate-limited, that check returns no signal; a blank is a blank, not a conviction.

• Hard tier (always on) — a package is flagged unmaintained only on a hard signal: the repo is archived, the latest npm version is deprecated, or the repo carries an "unmaintained" / "abandoned" / "no-maintenance-intended" topic.
• Soft tier (opt in with --soft) — heuristics like a dead release cadence, dormant commits, a stale issue backlog, a solo maintainer, or a low OpenSSF "Maintained" score only ever produce the gentler "probably" tier.

Advisory, not a gate

By default it is report-only and exits 0 — it advises, it does not block. Teams that want teeth add --strict, which makes a hard-tier finding fail CI. There is no sidecar, no allowlist, nothing to game: just a fresh read of public data each run. A scan with --soft looks like this:

✗ request@2.88.2 is unmaintained
    • request is flagged deprecated in its latest version 2.88.2.
    • request's last release was 6.3 years ago (2020-02-11).
    • request scores 0/10 on the OpenSSF Scorecard "Maintained" check.

? chalk@5.6.2 is probably unmaintained
    • chalk has a single npm maintainer — a higher bus-factor risk.

Engineering notes

Two runtime dependencies (commander and chalk) and the built-in fetch — a tool that scrutinizes your dependency health should not drag in a long tail of its own. Every release is published from CI with npm provenance attestations, so each version on npm links back to the exact commit and workflow that built it.