I've been building ARCLUX — a repository intelligence tool (CLI + web dashboard) that maps your codebase into a dependency graph, traces impact ("what breaks if I touch this file?"), and runs 18 structural detectors (circular deps, dead code, orphan files, layer violations, etc).
Verified at meaningful scale — microsoft/vscode, facebook/react, and vitejs/vite all analyze successfully, not just small toy fixtures.
Language support:
- TypeScript, JavaScript, Python — full support
- Go, Java — parsing works, but same-package calls with no import statement (common in both languages) aren't resolved as edges yet
Honest state (this is v0.1.0-alpha):
- Very large/unusual repos (10k+ files, heavy monorepos) can currently time out or fail without a clear error — no size guard or progress streaming yet, that's next
- Some packages (search, persistent caching) are still stubs
I'm not trying to compete with enterprise tooling — this started as a personal project to actually understand codebases I work in, and it grew from there.
Would love feedback, bug reports, or PRs if any of this is useful to you.
Top comments (1)
Impact analysis is one of the trickiest things to get right at scale — worth flagging one failure mode I hit building something adjacent (MCP codebase-intelligence server): symbol lookups can silently resolve to a shadow/duplicate definition elsewhere in the repo (test fixtures, examples/ folders, etc.) and the wrong answer looks exactly as confident as a correct one. No error, just quietly wrong. Might be worth a detector for that specifically, alongside your circular-deps/dead-code/orphan-files set — a "same name, multiple definitions, which one resolved" check.
Respect for shipping the honest state section instead of polishing over the alpha gaps. Curious how you're handling incremental re-analysis on large repos once the size-guard work lands — full re-walk on every change, or something closer to file-scoped invalidation?
Starred it — will try it against a repo I maintain.