Why your monorepo audits are lying to you (and how to fix the rot)

We’ve all been there: running a dependency audit, seeing a tool report 100 "unused" files, and realizing with horror that half of those files are actually critical architectural hubs. Static analysis tools in the JavaScript ecosystem are historically built to be "safe"—they flag anything they cannot explicitly trace. But in a complex monorepo with circular dependencies, alias-heavy build tools like Vite, and custom workspace configurations, these tools often collapse. They stop auditing and start "pruning"—treating your architecture as a pile of junk to be deleted.

Most tools rely on simple pattern matching or basic Abstract Syntax Tree (AST) walks. They struggle to build a true Control Flow Graph (CFG) or identify Strongly Connected Components (SCCs). When an engine encounters a cycle in a monorepo, it doesn't see a complex architectural component; it sees a disconnected node, labels it "orphaned," and suggests a deletion plan that would effectively brick your build.

To audit an architecture correctly, you need to move beyond simple string resolution. You need deep AST and CFG parsing, utilizing high-performance parsers (like OXC) to map actual execution paths. You also need SCC analysis to detect circular dependency chains across package boundaries, coupled with worker-pool parallelization, because auditing 10,000 files in a monorepo shouldn't block the main process. By leveraging these core concepts, I developed entkapp to validate the structural integrity of a workspace.

Consider this audit log from an intentionally broken repository:
[Linker-DEBUG] Attempting to resolve package-a ... Resolved to: C:/.../package-a/index.js
🔄 Detecting circular dependencies...
⚠️ Detected 1 circular dependencies: Cycle #1: packages/package-a/index.js -> packages/package-a/index.js

Here, the engine is forced to acknowledge the structural reality, not just the file list. It validates the boundary, identifies the cycle, and reports the smell without blindly nuking the project. The goal of auditing isn't just to delete code; it’s to understand how that code is actually connected. Whether you use entkapp or any other deep-analysis engine, look past the "unused file" list and start looking for the architectural "cycles" in your own monorepo. What’s the weirdest circular dependency you’ve discovered lately? Let's discuss in the comments.