Dependency Graph Explorer
The same package name can refer to different installed versions depending on the requesting package’s node_modules path. Open a local npm v3 lockfile, choose a physical package path, and trace what it uses, what depends on it, the shortest route from the project root, strongly connected cycle groups and duplicate installed versions. This is a bounded read-only model of declared lockfile relationships, not an npm install or security audit.
Key features
- Resolve direct runtime, optional and root development edges through nested then hoisted node_modules paths
- Trace all reachable transitive dependencies and reverse dependents of a selected physical installation
- Show one shortest root-to-package path and a direct-neighbor diagram
- Find strongly connected cycles, same-name multi-version installations, unresolved targets and root-unreachable entries
- Cancel a large bounded analysis and download the full deterministic JSON report
How to use
- Load the nested-version, cycle or missing-target example, or choose a local package-lock.json v3 file.
- Leave the focus path empty for the project root or enter an exact packages-map path.
- Analyze the graph; unsupported paths, links and over-limit input are rejected explicitly.
- Select another physical package path to compare transitive dependencies and reverse change impact.
- Review the cycle/duplicate/missing findings and download JSON if needed.
Use cases
- Explain why one package receives a nested version rather than a hoisted one
- See which declared packages could be affected by changing an installed dependency
- Locate a dependency cycle in the lockfile’s physical graph
- Identify packages installed at multiple versions
- Spot missing declared targets and entries disconnected from the project root
Frequently asked questions
Which lockfiles are supported?
Only npm package-lock.json lockfileVersion 3 with a root entry and regular node_modules package locations. Workspace/link locations, pnpm and Yarn formats, npm v1/v2 files and package execution are outside this profile and are rejected rather than guessed.
How is a dependency path chosen?
For each supported dependency name, the analyzer checks a nested node_modules directory under the requesting package, then the package’s ancestors, then the project root. Edges identify physical installation paths rather than package names alone. It does not reproduce conditional exports or runtime module loading.
What is change impact?
Reverse reachability lists installed packages that directly or transitively declare a path to the selected installation. It is a review candidate set, not evidence that code uses the dependency or that a version change will break it.
Why are peer declarations excluded?
Peer dependency placement and satisfaction depend on npm install context. This profile counts peer declarations but does not create guessed graph edges. Runtime, optional and root development declarations are modeled; absent optional packages are shown as unresolved rather than assumed present.
How large a lockfile can I analyze?
Up to 2 MiB UTF-8, 2,500 package entries and 8,000 resolved or unresolved edges. The analysis yields between batches so Cancel can stop a large graph. UI tables/diagrams preview subsets; the JSON export contains all bounded findings.
Privacy
The lockfile is parsed in this browser only. No packages are installed and no registry or server is contacted. The JSON export includes package names, versions and paths; review it before sharing private project details.
Comments & questions