I Tested My Static Analysis Tool Against 4 Real Open-Source Repos. Here's What It Got Wrong.

Vishal Kelur — Sun, 12 Jul 2026 12:06:07 +0000

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 first result was wrong, and that was useful

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.

Testing against four real repos

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.

What I actually shipped from this

A monorepo-aware dependency resolver that checks the nearest relevant package.json, not just the root
A framework-convention registry for implicitly-invoked exports (starting with Next.js)
TypeScript/JS path alias resolution via tsconfig/jsconfig discovery
Stricter, consistent "unsafe to remove" defaults for anything in test files or test-helper directories

All four ship with 76 passing unit tests, 18 of them new.

The actual takeaway

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

I Built a VS Code Extension That Understands Your Codebase Without AI

Vishal Kelur — Tue, 23 Jun 2026 09:29:30 +0000

A few months ago, I kept running into the same wall: opening an unfamiliar codebase — sometimes my own, six months later — and freezing. Where does this app even start? If I touch this function, what breaks? Is this code even still used?
I couldn't find a tool that answered this deterministically. So I built one.
ArchSetu
It's a VS Code extension that does static analysis on JavaScript/TypeScript projects — no AI, no API keys, no internet connection required. Everything runs locally, on your machine, instantly.
What it actually does:

Cross-file call graphs — see how every function connects across your entire project
Blast radius analysis — know exactly what breaks before you change a function
Dead code finder — functions defined but never called anywhere
Entry point detection — every route, export, and event listener, so you know where the app starts
Codebase health dashboard — complexity hotspots, largest files, coupling, all in one view

Why not just use Cursor or Copilot?
Those tools are excellent at writing new code. They're not built to deterministically map what already exists — and on large codebases, they hit context/token limits that static analysis doesn't.
ArchSetu isn't trying to replace AI coding assistants. It's meant to sit alongside them — run it before you accept a big AI-generated diff, and you know exactly what it touches before you merge.
Where it's at right now
Very early — just published, free, looking for honest feedback from real projects. If you try it on something real and it breaks, confuses you, or misses something,

I'd genuinely like to know.
https://marketplace.visualstudio.com/items?itemName=Archsetu.archsetu