I've been building ArchSetu, a static analysis tool that finds dead code, undeclared dependencies, and risky code paths, fully offline, no AI involved, deterministic output every time.
Before launch, I wanted real proof it worked, not just tests I wrote myself. So I ran it against four real, actively maintained open-source repos, each with roughly 5,000 GitHub stars, and treated every finding as a hypothesis to verify, not a fact to trust.
Here's what happened.
The very first run, against Express.js, flagged the repo D grade, 85% dead code. That's obviously wrong for a framework millions of projects depend on. Digging in, the bug was in how my tool traced re-exports through index files, it lost track of usage across module boundaries. Once fixed, Express scored a B, 0% false dead code, and I added seven regression tests so it can't silently regress again.
That one bug set the tone for the rest of this testing round: don't trust a scary number, verify it.
I picked repos with different shapes on purpose: a monorepo API tool, a Next.js app, a plain library, and a single-maintainer editor.
stoplightio/prism (API mocking, monorepo, ~5k stars)
Dead code: clean, 0 findings.
Dependencies: initially flagged 37 packages as undeclared. All false positives, caused by my tool only checking the root package.json
in a monorepo instead of the actual sub-package that declared them. After fixing that, the list dropped to 6, and manual verification confirmed 5 genuinely undeclared dependencies. I filed an issue with Prism's maintainers for the confirmed ones.
liam-hq/liam (ER diagram generator, Next.js, ~5k stars)
Dead code: initially 21 findings. Several were Next.js framework-reserved exports, like generateMetadata
and ErrorPage
, functions the framework calls implicitly by file location, not something a plain call-graph trace would ever see as "used." My tool didn't know these conventions existed. After building a framework-convention registry, false positives dropped from 5 to 0 for this category.
Dependencies: a separate bug here too, bare imports like @/components/Foo
that resolve through TypeScript path aliases in tsconfig.json
, not real npm packages. My tool was flagging local file references as missing packages. Fixed with proper tsconfig discovery and path resolution.
gajus/slonik (PostgreSQL client library, ~5k stars)
Dead code: 1 finding, a function only called from inside a .test.ts
file via test-runner discovery, not a direct call-graph reference. My tool correctly marked it "unsafe to remove," but that pointed to a broader gap, test-invoked functions have a different risk profile than production code and deserve stricter defaults.
Hufe921/canvas-editor (canvas/SVG editor, single maintainer, ~5k stars)
Dead code: 8 findings, all correctly marked "unsafe to remove." Six were test helper/factory functions, same pattern as slonik. The other two lived in a plugin-registration directory, a pattern my tool doesn't fully recognize yet.
package.json
, not just the rootAll four ship with 76 passing unit tests, 18 of them new.
Well-maintained real-world repos mostly don't have obvious, confidently-fileable dead code lying around. Most of what looked like findings were actually gaps in my tool's understanding of real-world patterns: monorepos, framework conventions, path aliases, test-runner invocation. Finding and fixing those gaps against real code was worth more than any synthetic test suite I could have written myself.
If you want to see where this goes next, ArchSetu is close to launch. Feedback on false positives, especially against your own weird real-world codebase, is genuinely the most useful thing you could send me right now at archsetu@gmail.com