# Dependency visualization tool

**URL:** <https://discuss.ocaml.org/t/dependency-visualization-tool/7964>\
**Category:** Ecosystem\
**Tags:** dependencies, opam\
**Created:** [June 4, 2021, 11:35am UTC](https://discuss.ocaml.org/t/dependency-visualization-tool/7964 "2021-06-04T11:35:51Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![XVilka](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/xvilka/32/5334_2.png) [@XVilka](https://discuss.ocaml.org/u/XVilka)\
**Post date:** [June 4, 2021, 11:35am UTC](https://discuss.ocaml.org/t/dependency-visualization-tool/7964/1 "2021-06-04T11:35:51Z")

</div>

Google recently [introduced a new dependency visualization tool - Insights](https://opensource.googleblog.com/2021/06/introducing-open-source-insights-project.html). Currently they support NPM (JS), Go, Maven (Java), Cargo (Rust).

 ![image](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/c/c2568a9efd9a6a1602961c11b2dbdae5937d82c6.png)  
 ![image](https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/a/a11f6b65885603b13d7fe0f1d187d8f1cf342ec1.jpeg)

[https://deps.dev/](https://deps.dev/)

Maybe it would be beneficial for OCaml community/ecosystem join the efforts. Also the OCaml-on-JS part of our community as well.

---

<div class="post-metadata">

**Author:** ![Chet\_Murthy](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/chet_murthy/32/1501_2.png) [@Chet\_Murthy](https://discuss.ocaml.org/u/Chet_Murthy)\
**Post date:** [June 8, 2021, 8:02pm UTC](https://discuss.ocaml.org/t/dependency-visualization-tool/7964/2 "2021-06-08T20:02:32Z")

</div>

In the past, I’ve found doing this sort of dependency-graphing to be very useful for figuring out where modularization in a large system needs to be applied. And it’s not very hard to do, based on ocamldep output or other dependency information that already exists.

On a lark, I wrote something that did this for installed findlib packages:

> **[chetmurthy/not-ocamlfind](https://github.com/chetmurthy/not-ocamlfind#package-graph)**
>
> front-end to ocamlfind (from findlib) to add a few new commands - chetmurthy/not-ocamlfind

I mention this not to plug the tool, but rather, just to note that it’s really easy, and yeah, people should avail themselves of this more.

---

<div class="post-metadata">

**Author:** ![kanishka](https://avatars.discourse-cdn.com/v4/letter/k/3e96dc/32.png) [@kanishka](https://discuss.ocaml.org/u/kanishka)\
**Post date:** [June 8, 2021, 10:19pm UTC](https://discuss.ocaml.org/t/dependency-visualization-tool/7964/3 "2021-06-08T22:19:36Z")

</div>

I like how [npmgraph.js.org](http://npmgraph.js.org) also lets you select the coloring based on various scorings of each library.

---

<div class="post-metadata">

**Author:** ![Gopiandcode](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/gopiandcode/32/5346_2.png) [@Gopiandcode](https://discuss.ocaml.org/u/Gopiandcode)\
**Post date:** [November 3, 2021, 7:11am UTC](https://discuss.ocaml.org/t/dependency-visualization-tool/7964/4 "2021-11-03T07:11:19Z")

</div>

> [@Chet\_Murthy](#):
>
> In the past, I’ve found doing this sort of dependency-graphing to be very useful for figuring out where modularization in a large system needs to be applied. And it’s not very hard to do, based on ocamldep output or other dependency information that already exists.

My goto command for this is `feh =(ocamldep * | ocamldot | dot -Tpng -Gdpi=300)` - it’s very useful for both exploring new codebases and doing larger refactoring work.