I built a dependency health scanner in a day. Here's what I shipped and what I cut.

varalaakshay-arch — Wed, 20 May 2026 06:45:50 +0000

A few weeks back I inherited an old Node.js project and spent half a day grepping package.json trying to figure out which libraries were still alive. npm outdated told me which versions had updates. npm audit told me about CVEs. Neither told me what I actually needed to know: which of these packages have been quietly abandoned and what the community moved to.

So this past week I built one. It's called stack-rot, it's written in Python, and it's now on PyPI: pip install stack-rot.

This post is about what I shipped, what I cut, and the one decision that mattered more than the code.

What it does

Point it at a package.json and it tells you which dependencies are:

Abandoned — community has moved away, even if the registry doesn't say so (moment is the classic example)
Deprecated — officially flagged on npm or by maintainers (request, node-sass, tslint)
Healthy — actively maintained

For each problem dependency, it tells you why it's flagged, links to public evidence (a maintainer's announcement, an archived repo, a deprecation flag), and suggests alternatives.

Sample output on a real scan of Ghost:

🪦 ABANDONED (1 package):
  ❌ moment 2.24.0
     → In maintenance mode since 2020.
     → Migrate to: dayjs, date-fns, luxon

⚠️ DEPRECATED (2 packages):
  ❌ brute-knex 4.0.1 — Package no longer supported
  ❌ path-match 1.2.4 — Archived and no longer maintained

✅ HEALTHY (207 packages)
📊 Project health: 9.9/10

Why a new tool

The honest version of the comparison table:

Tool	What it focuses on
`npm outdated`	Newer versions exist
`npm audit`	Security vulnerabilities
Dependabot	Automated version bumps
Snyk	Security + license issues
Socket.dev	Supply-chain risk
stack-rot	Community migration intelligence

None of the existing tools answer the question developers actually ask when they open an inherited codebase: which of these packages should I stop using? That's the question stack-rot answers.

The two signals

Every scan combines:

A hand-curated database (rot-db.json) of packages known to be dead, deprecated, or abandoned. Each entry has a status, a reason, suggested alternatives, and a public evidence URL. Started with 8 entries in v0.1. Every single one verified against the original source.
Live npm registry data for every other package — uses the deprecation flag npm itself maintains.

The curated database wins when both fire. Human-verified evidence beats automated flags.

What I cut

The original plan called for shipping 50 curated entries on day one. I shipped 8.

Here's why. I had a list of about 50 "obviously dead" packages in my head — names every Node dev recognizes. I started writing entries for them. Around entry 10, I had a gut feeling about a couple and decided to web-search before writing more. Two of my "definitely dead" picks turned out to be wrong:

gulp — last in my head as a "task runner from the 2010s nobody uses anymore." Actually shipped Gulp 5.0.0 in March 2024 with breaking changes and active maintenance.
grunt — same vibe. Published a 1.6.2 release three weeks ago, under OpenJS Foundation governance, with around 3 million weekly downloads.

If I'd shipped those entries, the first user to run stack-rot against a project using gulp would have tweeted "your tool says gulp is dead but it's actively maintained" and credibility dies on day one.

So I cut from 10 to 8. The 8 I kept are all verified — moment, request, node-sass, tslint, bower, coffee-script, phantomjs, phantomjs-prebuilt. Each has a primary-source evidence URL. The other 42 can wait for community PRs that go through the same verification process.

The lesson: a small dataset that's 100% correct beats a large dataset that's 90% correct. Especially on day one.

What's on the roadmap

v0.1 is JavaScript only. The roadmap, in rough order:

v0.2 — Python (requirements.txt, pyproject.toml)
v0.3 — Automated abandonment signals (last-publish dates, repo activity)
v0.4 — Go (go.mod)
v0.5 — Rust (Cargo.toml)
v0.6 — Community sentiment data from public sources
v0.7 — JSON/HTML reports, CI mode, GitHub Action
v0.8 — Safe codemods for trivial migrations
v0.9 — Web dashboard and README badges
v1.0 — Stability and sustainability

The curated database grows by community contribution. Each PR has to include public evidence, working alternatives, and the right schema. Rules are in CONTRIBUTING.md.

Try it

pip install stack-rot
cd your-project
stack-rot

Requires Python 3.10 or newer.

Source: https://github.com/varalaakshay-arch/stack-rot
PyPI: https://pypi.org/project/stack-rot/

If you've worked on dependency tooling or run a project that depends on something you suspect is abandoned, I'd love to hear from you — either on GitHub or in the comments here.