Don't just find the broken import. Bypass it.

Dependency Graph — zero build, survives a crash, injects a fix.

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.

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)
Parser engine initialization aborted.
in Studio/src/components/panels/AIPanel.jsx

at initializeParser (Engine/src/TreeSitter.js:32:11)
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
→ 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
specifiers { parserInstance }
source ./TreeSitter.js
resolvedSource Engine/src/TreeSitter.js
error Parser engine initialization aborted · Line 32, Column 12
interceptor [ intercept source... ]
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 bottom-left isolates just the nodes caught in a loop. Inside the inspector, a node in a cycle shows the full closed-loop chain — and hovering the chain highlights every related node on the canvas, while clicking a name in the chain selects and focuses that file. Circular imports are the quiet cause of a whole genre of bugs — a module that’s undefined at first access, lazy chunks that won't split, "works on the second hot-reload" gremlins. The graph just shows you the loop instead of making you find it by accident.

The part that’s actually new: bypass the broken module

Finding the blinking node is good. But the Dependency Graph goes one step further than any read-only map: it lets you swap the broken dependency for a mock and bring the render back — without editing the file and without a rebuild. Two injection levers, both in the inspector:

• Interceptor — match on the import ... from 'yyy' declaration. The source string shown on the node is exactly the word you intercept.

• Override — match on the final physical path the system resolved to. The resolvedSource on the node is exactly the path you override.

Configure either, then click the highlighted Apply Dependency Injection button in the top toolbar. Studio injects your rule into the current rendering context and attempts to restore the visualization — the deep, crashing module is now standing in for itself with something that renders. And the rules auto-persist, keyed by the entry file: reopen the same page tomorrow and your injection is already in place.

A read-only graph tells you where it broke. This one lets you route around the break and keep working — the file untouched, the page alive.

The render-error resolution flow

1. Locate the blinking node. Open the graph from the error overlay’s Show Dependency Graph link. The module that crashed the render is already blinking.

2. Investigate the root cause. Follow the line/column on the node, double-click to open that exact file, and find the offending code.

3. Isolate with injection. If a deep dependency is the cause, set an interceptor (on source) or override (on resolvedSource) in the inspector to swap it for a mock.

4. Apply to restore the render. Click Apply Dependency Injection. The rule is injected into the rendering context and the page attempts to come back — no rebuild.

5. Persistence handles the rest. Your rules are saved locally against this entry file and restored automatically next time. Re-enter nothing.

Dependency graph — CrossUI Studio

Why this is the same thesis as everything else

If you read our first post, this will feel familiar. The reason a CrossUI visual edit produces a one-line git diff is the same reason the Dependency Graph survives a crash and can inject around it: we treat your parsed source as the source of truth, and every surface is just a view over that AST.

The canvas is a view over the AST. The prop inspector is a view over the AST. The Dependency Graph is a view over the AST across files — and injection is a controlled rewrite of how one edge resolves. None of it depends on your app successfully running, because none of it is built on the runtime. That’s a constraint we chose on purpose — it’s harder to build, and it’s exactly what keeps the tooling alive in the moments runtime tools abandon you.

What it can’t do — honestly

Static analysis buys unconditional availability by giving up runtime knowledge. The boundaries are real and we’d rather name them:

• Fully dynamic imports are unresolvable. A dynamic import('./pages/' + name) with a runtime-computed path can't be resolved statically - we mark the edge rather than guess wrong.

• It shows structure, not values. The graph tells you AIPanel reaches TreeSitter; it can't tell you what the parser returned this particular render. Injection mocks the dependency; it doesn't replay the runtime state.

• Exotic resolution needs config. Non-standard bundler aliases or monorepo path magic resolve best when we can read your tsconfig / jsconfig. Without it, some edges fall back to raw specifiers.

None of those change the core promise: the graph is there when you’re stuck, and it can route you around the break — because it never needed your code to run.

→ Open Studio — crash a deep dependency, watch the graph point at it, then inject a mock and click Apply.

About CrossUI Studio — A visual IDE for React & MUI. Code and canvas stay in two-way sync on the same AST: edit code and the canvas updates live; click an element on the canvas, edit its props visually, and the code changes with a surgical one-line diff. No build, no localhost — it runs in the browser, works on your real Git repo or a local folder, with no vendor lock-in.

Try it free → studio.crossui.com

Originally published at https://blog.crossui.com on June 5, 2026.