dead-deps — what happened to your dependencies

Find the dead dependencies in your lockfile — and what replaced them

dead-deps reads your lockfile, works out which dependencies have genuinely stopped being maintained, and tells you what the ecosystem moved to instead. Every verdict comes with sources you can check.

npx dead-deps

No install, no account, no upload. It reads package-lock.json, pnpm-lock.yaml, yarn.lock or package.json, asks public registry indexes about each dependency, and prints the ones that have stopped moving — worst first. It exits 1 when something is flagged, so it works as a CI gate.

What it actually tells you

Most tools that look at dependency health return a number. A number cannot be acted on. dead-deps returns a state and a successor:

A quiet package is not a dead package

The naive detector reads the date of the last release and calls anything old dead. It fails immediately, because the npm graph rests on tiny packages that were finished years ago — once, inherits, wrappy, util-deprecate. They do one small thing correctly, so nobody commits to them, and on release date alone they are indistinguishable from abandonware. A tool that tells you to migrate off inherits has not found a problem; it has become one.

So stable-complete is its own verdict, guarded by its own rules, and the false-positive rate over a hand-labelled corpus of finished packages is measured separately. That is the part worth reading: how verdicts are produced, and the stable-complete guard.

The succession dataset

Knowing a package is dead is half an answer. The other half — what replaced it — cannot be computed, so it is curated by hand. Each of the 81 rows below records how the succession happened (a community fork, a rename, an unrelated replacement, functionality absorbed into the platform, a successor the maintainers declared themselves, or a reimplementation), whether the successor is a drop-in, and at least one primary source.

Roughly a fifth of real successions do not point at a package at all. left-pad was absorbed by String.prototype.padStart; q by native promises. "Delete the dependency, the platform does this now" is a better answer than any package name, so the dataset can say it.

Rows about small, finished, still-working packages are deliberately excluded. Being quiet is not being abandoned. Read the schema and inclusion rules before proposing a row.

Every package covered (81)

One page per package, each answering the question people actually type: is it still maintained, what replaced it, and is the replacement a drop-in.

A

B

C

E

F

G

H

I

J

K

L

M

N

P

Q

R

S

T

U

V

W

Z

From an editor or an agent

The same engine ships as an MCP server, so an assistant working in your repository can scan the lockfile, check a single package, or look up a successor without shelling out:

npx dead-deps-mcp

It exposes scan_lockfile, check_package and find_successor over stdio. Point your MCP client at that command.