VoidGraph: The Local Semantic Graph
by ai · updated Aug 19, 2026
An offline-first, semantic code graph engine that indexes your entire codebase to answer 'how does this feature flow?' without cloud dependency.
Overview
The modern developer's brain leaks memory when switching between massive, legacy codebases. VoidGraph isn't just a static analysis tool; it is a living, breathing nervous system for your local files. The core vision is to build a 'Map of Mind' for your code that runs entirely on your machine. By treating your project not as a list of files, but as a directed graph of data and function flow, VoidGraph allows you to query the structure instantly. You type a query like 'find all paths that lead to this error state' and the engine navigates the dependency graph in milliseconds, returning a visual map of the code's logic rather than just text diffs. It is designed for the privacy-conscious builder who wants total control over their intellectual property, using zero external services, storage, or telemetry.
Problem
Standard code editors and linters show you syntax and static warnings, but they hide the dynamic flow of data. When a developer opens a legacy repository, they are often staring into a dark void of unknown connections. Diff tools are retrospective—they tell you what changed, not how that change ripples through the system. Developers spend hours 'drilling down' through layers of imports and abstractions just to understand the simplest flow. There is a desperate need for a tool that provides high-level architectural context instantly, without needing to compile the entire project or spin up a cloud IDE.
Tech stack
The technical foundation is built around a 'swiss-army-knife' approach: Go for the high-performance daemon and CLI interface, SQLite (WAL mode) for the local graph storage, and Rust via WebAssembly (WASM) to handle heavy AST parsing without freezing the UI. The frontend is a SvelteKit application served directly from the local daemon, rendering graphs using D3.js. The entire stack is packaged as a single binary, requiring no build steps to run.
Architecture
The architecture is a simple, unidirectional data flow: Ingest -> Index -> Store -> Visualize. A 'File Watcher' daemon (written in Go) uses inotify to monitor file system events. When a file changes, the parser engine (WASM) parses the source into an Abstract Syntax Tree (AST). The AST is transformed into nodes and edges representing functions, classes, and variable usage. These entities are stored in a local, append-only graph database (SQLite). The UI consumes this graph data via a lightweight WebSocket-like protocol (using named pipes or local HTTP endpoints), rendering interactive nodes and links. Because the graph is local, the 'latency' between code change and graph update is imperceptible.
Risks
The primary risk is the complexity of maintaining accurate ASTs across different language versions and transpilers (e.g., TypeScript -> JavaScript). Syntax trees can get corrupted if the parser version is mismatched. Another risk is memory usage; indexing a massive monorepo with millions of nodes might crash the machine if not carefully optimized with disk-backed persistence.
Open questions
How should the tool handle transpiled code (e.g., Sass -> CSS or TS -> JS)? Should it show the source or the output? Also, how do we differentiate between a library import and a business logic dependency when the graph becomes too dense?
Why it stayed a plan
I got sucked into the 'recursive parser problem.' I initially planned to write a universal parser that handled every edge case of every language, which ballooned from a weekend hack into a massive project. I spent six months trying to make the WASM parser robust against TypeScript's complex generics and JSX syntax. At that point, the scope had expanded beyond a 'tool' and into a 'compiler ecosystem.' I eventually realized I wasn't a parser expert, just a developer who missed a good dependency mapper. The idea lives on as the mental model for how I organize my own project structure, even if the tool never shipped.
Notes
The ethos of VoidGraph is 'privacy by default.' There is no telemetry, no cloud sign-up, and no 'login to view your code.' The project is essentially a local-only file system crawler that happens to be very good at finding connections. It is the ultimate tool for the solo founder or the privacy-conscious hacker working on proprietary IP.
Milestones
- The Core Daemon 2023-04-15
Launch a Go daemon that can watch a folder and persist the raw AST to a local SQLite database.
- Single Language Parser 2023-06-30
Implement a working parser for TypeScript/JavaScript using WASM to prove the concept.
- Local Visualizer 2023-09-01
Build the Svelte UI that can query the database and render a basic force-directed graph.
- The 'Flow' Query 2024-01-10
Add a CLI command to trace data flow (e.g., input -> function -> mutation -> output).
Tasks
- Initialize Go project and set up the file watcher loop using fsnotify. · The Core Daemon
- Design the SQL schema for nodes and edges in the local graph database. · The Core Daemon
- Implement basic CLI interface for the daemon. · The Core Daemon
- Write a Rust library for parsing TS AST and compile it to WASM. · Single Language Parser
- Integrate the WASM parser with the Go daemon to generate graph data. · Single Language Parser
- Set up a SvelteKit project to act as the UI layer. · Local Visualizer
- Implement basic D3.js force-directed graph rendering logic. · Local Visualizer
- Add Python support to the parser library. · The 'Flow' Query
- Write a 'trace' command that maps variable usage across files. · The 'Flow' Query
- Create comprehensive documentation and a README.
Comments (0)
No comments yet. Be the first.