A VS Code extension that reverse-engineers an Angular/Ionic app's user flow — how a user
actually moves through the app's screens — directly from the codebase, and renders it as an
interactive diagram. No manual documentation, no guessing: it reads the routing config and the
navigation calls in your components and templates.
What it does
Scans the open workspace for Angular Router config (*-routing.module.ts, *.routes.ts,
app.routes.ts), including nested children routes and lazy-loaded loadComponent /
loadChildren routes.
Scans .ts and .html files for navigation calls: navCtrl.navigateForward(),
navCtrl.navigateRoot(), router.navigate(), and routerLink in templates.
Builds a graph: nodes = screens/pages, edges = transitions between them.
Renders it as a flowchart in a VS Code webview (solid line = declared route, dashed line =
an actual navigation call in code — useful for spotting screens that are routable but never
actually linked to, or vice versa).
Setup (one-time, ~2 minutes)
Open this folder (workflow-visualizer) in VS Code.
Run npm install in a terminal.
Run npm run compile (or leave npm run watch running).
Press F5 — this opens a second "Extension Development Host" VS Code window with the
extension loaded.
In that new window, open your actual Angular/Ionic project folder (File > Open Folder).
Open the Command Palette (Cmd/Ctrl+Shift+P) and run:
"Workflow Visualizer: Show App User Flow"
A panel opens with the diagram. Solid arrows = routes; dashed arrows = navigation calls found
in code.
Packaging as a real installable extension (optional, for extra polish)
npm install -g @vscode/vsce
vsce package
This produces a .vsix file you can install into any VS Code via
Extensions > ... > Install from VSIX, so you're not tied to the F5 dev-host during your demo.
Suggested live demo script (3-4 minutes)
Open with the problem (30s): "When we onboard a new dev, or when we're scoping a change,
nobody has an up-to-date picture of how a user actually moves through this app. Diagrams get
stale the moment someone adds a screen."
Run it live (60s): Open the real project, run the command, let the diagram render.
Narrate what you're seeing as it appears.
Point out one real insight (60s): Look for something genuinely useful in your project's
output — e.g. a screen that's declared as a route but nothing navigates to it (dead route),
or a screen with far more incoming transitions than expected (a de facto hub). This is the
"analyst" moment — you're not just showing a diagram, you're showing what it reveals.
Close with the "so what" (30s): How this would help onboarding, code review, or planning
a refactor. Mention it's a real installable extension, not a one-off script.
Known limitations (be upfront about these if asked — it reads as credibility, not weakness)
Navigation targets passed as variables (navCtrl.navigateForward(this.someVar)) aren't
resolved — only string literals are tracked.
It doesn't execute the app, so conditionally-rendered navigation (e.g. behind a feature flag)
shows up the same as any other edge.
Route guards (canActivate) aren't reflected in the diagram.
These are natural "if I had another sprint" talking points — good material for the Q&A.
