Developer Tool · Graph Algorithms · GitHub API · 2026 · Solo build
Mesh Guard
Every coupling, cycle, and architectural boundary in your codebase — mapped live from GitHub, enforced with one ESLint config.
The problem
Mid-level and senior engineers inheriting a React, Node, or TypeScript monolith face an invisible coupling problem: every refactor cascades into 40 broken tests because the module boundaries are unknown. Static analysis tools show which files import which, but not where the dangerous SCC cycles live, which files are the most expensive to change (high instability, high fan-in), or how to enforce an architectural wall once you draw one. Mesh Guard fills the gap: enter a public GitHub repo URL, get a force-directed graph of the real import graph, cyclic SCC clusters highlighted, Martin instability radius encoded on each node, then draw boundary zones and export an `eslint-plugin-boundaries` config that enforces your decisions in CI.
Architecture
Key decisions
Iterative Tarjan SCC to survive large repos
The canonical recursive Tarjan implementation blows the JavaScript call stack on repos with 4000+ files (React, Next.js). The iterative version uses an explicit stack of {node, neighborIndex} frames and mirrors the recursive low-link update with a post-visit step. This makes it correct for arbitrarily large graphs without needing to raise stack limits. Confirmed on vitejs/vite (593 nodes, 1048 edges, 9 cyclic SCCs) in production.
Martin instability metric for change-cost visibility
Fan-in/fan-out counts alone do not distinguish safe dependencies from dangerous ones. Robert C. Martin's instability metric (fan-out / (fan-in + fan-out)) surfaces the insight: a file with high instability and high fan-in is the most expensive thing in the codebase to change — everyone depends on it, but it depends on everyone else. Encoding this as node radius in the force graph makes the risky files visually prominent without a separate table.
Regex import parser instead of full AST
A full TypeScript compiler API (ts-morph, @typescript-eslint/typescript-estree) handles every edge case but requires running a TypeScript compilation in a serverless function with cold-start penalties and significant bundle weight. The regex parser handles ES module imports, CommonJS require(), dynamic import(), side-effect imports, and multiline statements — the 95% case for architectural analysis — and degrades gracefully on unusual syntax rather than throwing. 12 TDD tests cover its boundary conditions.
Consequential output: ESLint config, not a report
A coupling visualizer is educational; an installable ESLint configuration is actionable. The boundary-draw flow translates the user's spatial decisions (drag a box around 'components/') into an `eslint-plugin-boundaries` zones array and a rules array that can be committed to the repo and enforced in CI. This makes the product consequential — the user leaves with a file that changes what they can merge.