Loading…
Loading…
Visualize project dependencies as an interactive graph
Run your projects on Claude Code?
We packaged the .claude config that runs this site — 26 specialist agents, 14 workflow skills, and 6 rule files from 31 real production incidents. From $9.
Get the Claude Code Production Pack — $29Dependency graphs reveal the structural complexity of a software project at a glance. A package.json with 30 direct dependencies and 400 transitive dependencies tells one story; a force-directed graph that shows the clustering of dev dependencies versus production dependencies tells another. Manifest files for npm, pip, Go modules, and Rust Cargo each use different formats but all express the same information: which external packages the project depends on, at what version, and in what dependency class (production, development, peer, optional).
The parser reads the pasted manifest content and extracts package names, version constraints, and dependency class from the format-specific structure. For package.json, it reads the dependencies, devDependencies, peerDependencies, and optionalDependencies objects. For requirements.txt, it parses lines matching package==version, package>=version, and package[extras] patterns. For go.mod, it parses require blocks. For Cargo.toml, it reads the [dependencies] and [dev-dependencies] tables.
The extracted dependency list is converted to a graph data model with the project root as the central node and each dependency as a connected node. The graph is rendered using a force-directed simulation: nodes have repulsive forces between them and edges apply attractive spring forces. The simulation runs for a fixed number of ticks to reach a stable layout, then becomes interactive.
Node color encodes dependency class: green for production, orange for dev, blue for peer/optional. Node size reflects the number of dependents — packages required by many others appear larger. Clicking a node opens an info panel showing the exact version string and dependency class from the manifest.
A developer auditing a project before open-sourcing it visualizes the dependency graph to identify whether any commercial-licensed packages appear in the production dependency set.
A tech lead reviewing a pull request that bumps 15 dependencies visualizes the before and after graphs to assess whether the change significantly increases dependency complexity.
An engineer onboarding to a large monorepo pastes the root package.json to get a quick visual overview of the major dependency clusters before reading the codebase.
A developer preparing a security audit pastes requirements.txt to visually identify which packages have the most downstream dependents, prioritizing which ones to check for CVEs.
Paste your package.json, requirements.txt, go.mod, or Cargo.toml content
The tool auto-detects the format and parses all dependencies
An interactive force-directed graph renders with color-coded nodes
Click any node to see package details like version and dependency type
Export the graph as an SVG file for documentation or presentations
About the Codebase Dependency Visualizer
package.json (npm/yarn/pnpm), requirements.txt (Python pip), go.mod (Go modules), and Cargo.toml (Rust). The tool auto-detects the format from the pasted content.
Green nodes are direct (production) dependencies, orange nodes are dev dependencies, and blue nodes are peer or optional dependencies. The central node represents your project.
Yes, click the Export SVG button to download a vector image of the current graph. SVGs can be opened in any browser, embedded in docs, or edited in design tools.
No. All parsing and rendering happens 100% client-side. Your dependency data never leaves your device.
The parser uses structural heuristics: JSON with a "dependencies" or "devDependencies" key is identified as package.json; lines starting with package or require are identified as go.mod; [package] and [dependencies] sections identify Cargo.toml; lines in the format package==version or package>=version identify requirements.txt. The detected format is shown before rendering the graph.
The visualizer shows direct dependencies declared in your manifest file. Transitive dependencies (dependencies of dependencies) are not resolved because that requires network access to the npm, PyPI, or crates.io registries. For full transitive dependency graphs, tools like npm ls --all, pip-tree, or cargo tree produce the full tree from an installed environment.
A force-directed graph simulates physical forces between nodes: nodes repel each other (like electric charges) while edges attract connected nodes (like springs). The simulation runs until the system reaches a stable state. Highly connected nodes cluster together; isolated nodes drift to the edges. You can drag nodes to rearrange the layout and the simulation will re-stabilize around the new positions.
Builder/critic agent prompts with brakes built in
Open →DeveloperFormat, validate & diff JSON — runs entirely in browser
Open →DeveloperTest regex live — railroad diagrams + plain English explained
Open →DeveloperOne color in, full design system out
Open →