Don't just find the broken import. Bypass it. - CrossUI Studio — Symmetric Visual IDE

Author

User<br>linb<br>Posts by this author<br>Posts by this author

~9 min read · Engineering

A dependency five levels down throws, and your whole canvas goes white. CrossUI Studio's Dependency Graph still draws — zero build — points you straight at the blinking node, and then lets you inject a mock for the broken module to bring the page back. No file edit. No rebuild. That's the v0.9.5 story.

TL;DR. The Dependency Graph is built from static AST parsing, not a build — open a file and the import tree renders instantly, even when the canvas has completely crashed. The failing module blinks with its exact line/column. Then the part that's actually new: from the inspector you can set an interceptor or override to swap the broken dependency for a mock, hit Apply Dependency Injection, and the render comes back — rules auto-persist per entry file.

The blank-screen problem, five levels deep

A component blows up, but the component is never the culprit. Here's a real one. The canvas throws inside AIPanel.jsx:

Error (Canvas render — runtime)<br>Parser engine initialization aborted.<br>in Studio/src/components/panels/AIPanel.jsx

at initializeParser (Engine/src/TreeSitter.js:32:11)<br>at async Engine/src/TreeSitter.js:36:31

But AIPanel isn't where it broke. The real failure is in TreeSitter.js, line 32 — five imports down the chain:

AIPanel.jsx → AIJsxResponseReconciler.js → JSXParserEngine.js<br>→ CodeFormatter.js → TreeSitter.js ← throws here

Normally this is where the afternoon disappears: rebuild to reproduce, scatter console.logs down the chain, guess which import actually threw. And the tools built to help have all just gone dark — React DevTools shows nothing (no component mounted), the profiler has no render to profile, the error overlay gives you a line but not the shape of the code around it. They all need the app to run first. It didn't.

The one moment you most need to understand your code's structure is the one moment your code refuses to produce it.

Zero build, instant display

The Dependency Graph skips the build step entirely. Open a file and it parses the import tree to an AST and draws it in real time — no bundling, no dev-server round-trip, no waiting. That alone is the everyday time-saver: you see the whole reachable module graph the instant you ask for it, not after a rebuild.

And because the map is parsed from source rather than observed from a run, it has a property no runtime tool can match: it still renders when the canvas has completely crashed. A broken page isn't a dead end — it's the graph's primary entry point.

Two ways to know a codebase

There are only two ways for a tool to learn the shape of your project, and the difference decides everything about when the tool is available to you.

Runtime introspection — needs a successful render. React DevTools, profilers, error overlays. Reads the live fiber tree after mount, knows real prop values — but only if they exist. Goes completely dark when the render throws, and can't see a module that failed to initialize.

Static AST analysis — needs nothing to run. CrossUI's Dependency Graph parses each file to an AST and reads its imports. Knows structure — every edge, before execution — indifferent to whether the app renders, and maps the broken module and its neighbors.

Runtime tools are richer when they work. But they are conditional on success . Static analysis is poorer in some ways — it can't tell you what a variable held at 2:04pm — but it is unconditional . It works on a codebase that has never once rendered cleanly. That property is the whole point.

Reading the graph

Set any file as the ENTRY and the panel scans outward from it. Every node is tagged so you can place it at a glance: Entry, 📄 Local, 🌐 Ext, and ⟳ Cyclic.

Hover or select a node and animated lines trace its relationships in two directions — and the direction is the whole point:

Solid lines — downstream. The modules this file imports.

Dashed lines — upstream. The parents that import this file.

The search box highlights matching nodes live; the failing module blinks so your eye lands on it without hunting.

Click any node and the inspector slides out — your troubleshooting console for that file. It shows the resolved path, the raw source string and its resolvedSource, and, when parsing hit trouble, the exact error in red with line and column:

Inspector · TreeSitter.js 📄 Local<br>specifiers { parserInstance }<br>source ./TreeSitter.js<br>resolvedSource Engine/src/TreeSitter.js<br>error Parser engine initialization aborted · Line 32, Column 12<br>interceptor [ intercept source… ]<br>override [ override resolved path… ]

Navigation note: mouse-wheel pans vertically, Shift+wheel pans horizontally, Ctrl+wheel zooms on the cursor — so a huge graph stays fast to move through.

Cycles, in red and one click away

The engine detects circular references and draws the offending edge in red. A Show cycles filter in the...