Brian via matrix 
If I didn't mess up too badly, that is mostly the dependency graph for the Wiki-Client. I'm mostly exploring the code to get more familiar with the technical details of how it works.
khinsen via matrix Graphviz doesn't do a very good job with dependency graphs (and DAGs in general).
Here is what I do:
Compute a "layer number" for each node, which is one plus the largest layer number of any of the node's dependencies.
Group all nodes with the same layer number into a Graphviz cluster.
Set the box that Graphviz draws around each cluster to "white" so it becomes invisible.
That yields clear graphs up to much larger sizes. At some point they get rather wide (see example above) but without losing clarity. Only when the number of arrows becomes too large, it's a ball of mud again.
Ward via matrix
@khinsen
: I understand that Dot layout is already following a similar algorithm with its notion of "rank". Can you show us what your example looks like without your intervention?
I'm guessing
Brian
is mapping the wiki-client's network of "require" which regrettably has circularities making the notion of rank/level less revealing.
The jumble of dependencies in wiki-client may be due to the variety of entry points that range from a fresh rendering of a complete lineup, through incrementally revising a lineup in response to browser back/forward history, through adding, removing and moving pages within the lineup, to adding or editing items within a page. Much of this functionality was present before a "module" structure was asserted over what was once a single file full of functions. From this change we gained more benefit from namespace scopes than a clear dependence hierarchy. matrix