DEV Community

Cover image for Building an Obsidian-Style Code Intelligence Graph for Any JavaScript Project
VANSH ARORA
VANSH ARORA

Posted on

Building an Obsidian-Style Code Intelligence Graph for Any JavaScript Project

Most dependency graphs are useless after the first 30 seconds.

They show connections.

But they don't tell you what matters.

While building TokenCap v0.6, I wanted to answer a different question:

If I open a large codebase for the first time, which files should I care about?

That led to a complete redesign of TokenCap's graph engine. Instead of building another dependency visualizer, I started building what I call a Code Intelligence Graph.

The Problem

Traditional project graphs tell you:

File A imports File B
File B imports File C
File C imports File D

After a few hundred files, the graph becomes a spiderweb.

Interesting to look at.

Not useful for decision making.

What developers actually want to know is:

Which files are high impact?
Which files are risky to change?
Which modules are tightly coupled?
Which areas of the codebase belong together?
Which files should AI see first?
The Approach

TokenCap v0.6 analyzes the repository and assigns intelligence to every node.

Each file receives:

A node type
A cluster
An importance score
A risk score
Dependency relationships

The graph currently supports 13 node types:

Routes
APIs
Components
Controllers
Services
Databases
Middleware
Configs
Utilities
Hooks
Packages
Tests
Unknown files

Instead of seeing a wall of files, you immediately understand the structure of the application.

Risk Scoring

One of the most useful additions was risk analysis.

Every file is classified as:

CRITICAL
HIGH
MEDIUM
LOW

For example:

A heavily connected authentication middleware is far more dangerous to modify than an isolated utility function.

That sounds obvious.

But visualizing it changes how you navigate a codebase.

Clustering the Codebase

The graph automatically groups related files into clusters such as:

Authentication
Payments
Dashboard
Database
API
Frontend
Config
Testing

This ended up being one of my favorite features because it makes large repositories feel significantly smaller.

Building the Viewer

The graph viewer uses a three-panel layout:

Filters and graph controls
Interactive graph canvas
Node intelligence panel

You can:

Hover nodes to reveal dependencies
Switch between global and local graph modes
Filter by type or cluster
Inspect impact, risk, and relationships
Explore architecture visually

The goal was to make code navigation feel closer to Obsidian's knowledge graph than a traditional dependency tool.

Lessons Learned

The biggest takeaway from building v0.6 is that developers don't need more information.

They need better prioritization.

A repository might contain thousands of files.

But only a small percentage actually drive architecture, risk, and decision making.

The challenge is identifying those files quickly.

That's the problem I wanted the graph to solve.

What's Next?

The graph is already functional and useful, but it's still the area I'm most interested in improving.

Future iterations will focus on richer relationships, smarter impact analysis, and tighter integration with AI-assisted workflows.

The long-term goal is simple:

Help both developers and AI understand a project faster.

Not by showing more code.

By showing what matters.

npm package - https://www.npmjs.com/package/tokencap
website - tokencap.vansharora.app

Top comments (0)