If you’ve ever felt buried under a sprawling Cargo.lock, wondered “Which crate dragged in all these transitive deps?” or “Why do I have two versions of foo-crate in my workspace?”, then meet dep-insight: a CLI + library tool designed to give you clear, actionable visibility into your Rust project’s dependency graph.

---

Why I built it

In many non-trivial Rust codebases I work or consult on, I keep seeing the same patterns:

• Duplicate crate versions sneaking in (hello, serde 1.0.130 and serde 1.0.131 side by side)
• One transitive ancestor crate pulling in dozens of downstream modules, silently ballooning compile times and binary size
• License rustle: “Wait, is this dependency licensed permissively? Or do I need to worry?”
• Security: “Do we have known vulnerabilities via rustsec in our dependencies?”

In short: I needed clarity. I needed dep-insight.

---

What it does — and how

At its core, dep-insight does three important jobs:

1. Analyze

You run:

cargo install dep-insight
cd your-rust-workspace/
cargo dep-insight analyze

It walks your Cargo.toml + lockfile, builds the dependency graph, finds duplicates (same crate, multiple versions), flags crates with large transitive footprints, and gathers metadata (licenses, optional RustSec vulnerabilities) when configured.

2. Visualize

Need to show the team a picture rather than a wall of text?

cargo dep-insight visualize --out deps.html --no-open

Generates a self-contained HTML file with an interactive D3.js graph of your crate-dependencies. You can hover, zoom, see “aha” moments like “this one crate is pulling in 45 others”.

3. Integrate & Automate

It outputs JSON too — perfect for CI checks. Want your pull requests to fail if duplicate versions appear? Build automation on top of the JSON output. Want a nightly audit report? Plug it in. You can also enable the audit feature to incorporate rustsec vulnerability scanning and license checks.

---

When & how to use it

• Pre-release audits: Before tagging a release, run analyze + visualize, inspect large dependency clusters, ask: “Do we really need that crate dragging in a hundred deps?”
• CI/PR gate: Hook into the JSON output; fail if duplicates > 0 or forbid non-permissive licenses.
• Team onboarding / documentation: Use the HTML visualization as a baseline snapshot of your project’s dependencies—so new devs get a big-picture view fast.
• Dependency cleanup sprints: Pick an analysis report, pick the “top heavy” crate(s), ask “Can we remove / replace this with a lighter alternative?” and track progress over time.

---

What it gets right

• It’s written in Rust and built for Rust projects — no awkward cross-language adaptation.
• Works offline (by default) unless you enable online features — good for locked-down CI environments.
• A dual interface: CLI for devs, JSON for machines, HTML for humans and teams.
• Strong “refactoring value”: duplicates + footprint flags directly correlate to maintenance and build-time savings.

---

What’s still worth improving

Nothing’s perfect, and I see a few areas where dep-insight can push further:

• A GitHub Action integration would be killer — e.g., automatically generate the HTML, upload as an artifact, comment on PRs with a summary.
• Incremental caching of crates.io metadata would speed large workspace analyses.
• A SARIF or compatible standard format for vulnerability/license results (so security dashboards can ingest them) would enhance enterprise adoption.
• More examples or boilerplate code showing how to embed the library in custom tooling or dashboards could lower the barrier for consumers.

---

Bottom line

If your Rust project is more than “a handful of crates”, you’ll likely uncover hidden debt: duplicate versions, unintended heavy subgraphs, license surprises. Half the battle is visibility — knowing what you depend on. dep-insight gives you that visibility, and makes it usable (and shareable) across your team.

Give it a spin:

cargo install dep-insight
cargo dep-insight analyze --json report.json
cargo dep-insight visualize --out deps.html

Inspect the output, share the HTML, ask your team “Do we really need that crate?” and start trimming the unseen baggage.

If you try it and hit weird results, or have ideas for integrations (like GitHub Actions, dashboard plugins, etc), I’d love to hear about them!

Happy refactoring 🙂 — Eshan (CEO @ Tonmoy Infrastructure)