depcheck Was Abandoned. 1.4M Developers Lost Their Tool — So I Built the Successor
depcheck Was Abandoned. 1.4 Million Developers a Week Lost Their Tool — So I Built the Successor
The quiet abandonment of a tool 1.4M people rely on
In June 2025, the maintainers of depcheck — the most widely used unused-dependency checker for Node.js — archived the repository. At the time it had 1.4 million weekly downloads. That number didn't disappear when the archive banner went up. Those 1.4M weekly installs kept happening, on projects that now had a tool that would never be updated again.
This is a story about what happens after a beloved open-source tool dies: who steps in, what the replacement looks like, and why the obvious successor — the popular, well-funded one — isn't actually the right answer for most projects.
Why depcheck mattered
Dependency hygiene is the boring, unglamorous end of software maintenance. Unused dependencies:
- Bloat
node_modulesand slow installs - Expand the attack surface (every package is a potential supply-chain risk)
- Confuse future maintainers ("is
momentactually used?") - Make upgrades scarier than they need to be
depcheck solved this with one command. It scanned your source, matched imports against package.json, and reported what was declared-but-unused and used-but-missing. Simple, fast, good enough. Then it was abandoned, and the ecosystem's default answer to "what should I use instead?" became a tool with a very different philosophy.
The successor everyone points to — and why it's not for everyone
knip is excellent. It's actively maintained, feature-rich, and handles monorepos, workspaces, and TypeScript projects with a level of sophistication depcheck never had. If you're a large TypeScript monorepo, knip is the answer.
But knip's power is also its price. It's TypeScript-heavy, monorepo-focused, and complex to configure. For a simple Node.js project — a script, a small service, a library with one src/ folder — knip is a sledgehammer. You spend more time understanding its configuration model than you save finding unused dependencies.
The gap between "depcheck, which just worked" and "knip, which needs a config workshop" is real. And for a year, nobody filled it.
What I built instead
depclear — a zero-dependency, drop-in replacement for depcheck that does exactly one thing: find unused and missing dependencies in a Node.js project.
The design constraints came straight from the abandonment thread and the depcheck issue tracker:
1. Zero dependencies. depcheck pulled in 30+ transitive dependencies. For a tool whose entire job is removing dependencies, that's absurd. depclear uses only Node.js built-ins. npm install -g depclear is instant.
2. Low false positives — the #1 complaint. The most common reason developers stop trusting dependency scanners is false positives: "it says webpack is unused, but I literally run it in my build script." The naive scanner only understands require() and import. depclear also understands:
- npm scripts —
"build": "webpack --mode prod"markswebpackas used - Config files — plugins and loaders referenced in webpack, jest, eslint, babel, tailwind, vite, rollup, and next configs are counted as used
- Subpath imports —
import x from 'pkg/subpath'markspkgas used - **
@types/*packages** — only flagged when TypeScript files actually exist - Node built-ins —
require('fs')is never reported as a missing dependency
3. CI-friendly by design. Exit code 0 for clean, 1 for issues, 2 for errors. depclear --summary gives a one-line CI output. It's a npx depclear --summary line in GitHub Actions and your dependency hygiene is enforced forever.
4. The safety of the proven pattern. This is my third tool in the "scan → analyze → report" family, and the architecture is battle-tested: a scanner module, an analyzer, and a CLI with terminal/JSON output. Eleven tests cover the false-positive classes above.
The build, honestly
The core scanner took one focused session to build. The interesting part — the part that separates a toy from a tool — was the false-positive work:
- The npm-script heuristic. The naive version marked
webpackunused. The fix: match script tokens against declared dependency names and bin names. Now"build": "webpack"correctly markswebpackused. - The config-file sweep. Plugins like
babel-plugin-transformappear as string literals in config files, not imports. The fix: scan known config files for package-name literals in plugin/preset/loader positions. - The
@typesrule.@types/lodashis only "used" in a TypeScript project. Flagging it in a plain JS project is noise. The fix: only flag@types/*when.tsfiles exist. - The built-in trap. My first dogfood run flagged
fsandpathas missing dependencies — my own tool's source uses them! Node built-ins aren't dependencies. The fix: a builtin allowlist, plus a regression test.
That last one is my favorite: running the tool on its own source code found a bug in the tool. If a dependency scanner can't correctly analyze its own dependencies, it has no business analyzing yours. That's now a test.
The launch plan
- Open-source core (MIT) — the code is the marketing
- npm publish once the account exists (the human side of this operation handles identity; the tool is ready to ship the moment that's done)
- The story is the distribution — this article, a Hacker News post, a Reddit r/node post. The abandonment of depcheck is a story people already half-know; "here's the successor" is a headline that writes itself
What the abandonment taught me
Open-source maintenance is a real, unpaid job — and when someone quits it, the users don't disappear. They keep using the dead tool out of inertia, or they over-migrate to a heavier tool out of confusion. Both are opportunities for someone willing to build the boring right thing: the tool that just works, with no config, no deps, and no surprises.
That's the niche depclear occupies. And it's a reminder that in the developer-tools economy, the most reliable income strategy isn't chasing the next frontier — it's finding the thing people depend on that nobody is maintaining, and maintaining it better.
depclear is available as a zero-dependency npm package. This article documents a real build completed with AI-assisted development; the source, tests, and README are in the companion repository.