[feature] Graph view UX improvements

[mindplay-dk]

One of the main things I was hoping to get with this tool is a high level overview.

The graph view is theoretically good for this - however, in practice, well... 😌

UX Problems

This is clearly not useful - and this is a project with a comparatively very low number of first-party dependencies, compared to the average node JS project, in my experience. The team here has been exceptionally good at not bloating the project with dependencies - so you can imagine the experience is even less useful for the average NPM project. I'm sure you're familiar with the reality of node projects in the wild - it's what this tool is designed to help with, right? 😊

Of course, you can hover and point at things, but...

This is also not very useful, since you need to zoom in before you can even see what you're pointing at.

And I know you can click to focus an item and bring it's dependencies into view, but...

It's still really difficult to see what's going on at that level:

• The tooltip sits on top of the focused graph, making it really difficult to read.
• The view jumps and auto-zooms to the selected package, which makes you lose track of your position in the larger diagram.

Suggestions

• Force-directed graphs: this would be one way to get any amount of nodes to fit optimally on the screen. This package can do it very quickly, and has the ability to fit to canvas at startup or e.g. after resizing the window. This would automatically improve the hover state experience, because nodes that are closer to each other would actually be physically located closer to each other - it greatly improves the chance of hovering and actually seeing something useful, without need to click and change your view.
• Filters: if the depth could be adjusted (e.g. max n levels) and if the "key" (dependency, dev-dependency, sub-dependency) also worked as a filter for what's display, that would help a lot. A text input to filter by package name might help as well.
• Dock the selection info in a sidebar: this would likely be more helpful than the current tooltip - it wouldn't get in the way, and with an optimized graph layout, we probably don't need to be quite as conservative with space.
• Multiple selection: if a sidebar was added, this could enable you to filter/select the package you want to focus on.

These would be my suggestions for a more useful version of this screen. 😊

[JosephMaynard]

@mindplay-dk Thank you for your continued feedback, I am very grateful! As my possibility only user I feel compelled to try and keep you happy!

So I was aware that the graph view gets less useful as the dependency tree grows. I had in fact already considered using a force directed graph, but I thought they lost the hierarchy and also became hard to follow.

I have included 3 new views in the latest v1.1.0 release which you may find more useful.

I think the one you will be most interested in is the balloon tree layout view which shares some ideas with the force directed graph, but keeps the hierarchy easy to understand by using size. It does make the leaf nodes quite small in some cases, but I liked the fractal like structure and being able to get a better understanding of the full complexity with everything on screen at the same time.

The hyperbolic view is more experimental. I wanted to attempt to be able to keep the full representation of the dependency tree on screen while being able to see an individual piece in full detail. It doesn't really achieve that currently, but I think my perfect solution would be a combination of this with the balloon view. My attempts to build that combination have so far been unsuccessful...

The final view is probably the most boring, but potentially the most useful which is a flame graph, which most people will be familiar with from browser dev-tools.

You were right about the tool tip getting in the way, so I have added a sidebar with a search box. The filters you suggested are in there too: toolbar chips to show/hide runtime, dev, and sub-dependencies, plus a depth cap.

The one thing I haven't tackled yet is multi-select as I wasn't exactly sure what you were proposing. If you have a concrete workflow in mind for it (union of subtrees? comparison?), I'd be interested to hear.

Anyway, if you do get a chance to try everything out, I would love to hear what you think!

[mindplay-dk]

@JosephMaynard wow, thanks! these are really cool updates 😄

the flame view is particularly useful! how the heck does react-dates have 52 thousand dependencies? for a date-picker?? 😂

the balloon view is interesting as well - I feel like this gives me everything the graph view gives, but much better use of real estate.

the hyperbolic view I'm not really sure what to do with?

the filters are incredibly useful as well! being able to focus on runtime impact is priceless! 😊

great work, thank you for these updates!

[mindplay-dk]

the flame view is particularly useful! how the heck does react-dates have 52 thousand dependencies? for a date-picker?? 😂

these numbers aren't right though

https://pkg-size.dev/react-dates@21.8.0

I tested this locally as well - there are 128 dependencies, not 50.000 😅

are those numbers supposed to show dependency counts or what are they?

[mindplay-dk]

package installers will dedupe duplicate packages, perhaps that's the issue?

[JosephMaynard]

@mindplay-dk Thank you for testing the release!

So technically the numbers you were seeing were correct, the counts came from all of the paths, which get used for sizing everything on screen, bar widths in the flame view and the circle sizes in the balloon view are proportional to them, however I can now see that we didn't make that very clear...

With paths, every distinct route from your project to a package counts once, flame-graph style, so a shared package deep in the tree gets counted once per route it's reachable by. That's how react-dates' 128 packages became ~52,000, but the labelling did not tell you that.

I have just released v1.1.1 which, I hope, makes everything more clear. I also got 3 different frontier AI models to do a deep adversarial code review which surfaced a few deep-rooted bugs, so this should also be the most solid release yet:
https://github.com/JosephMaynard/dependency-radar/releases/tag/v1.1.1

If you have any more feedback, I would love to hear it!

[mindplay-dk]

I guess I still don't understand what the 52.000 number represents, or how it's useful? "once per route it's reachable by", does that number tell me anything? 😊

what I would probably expect to see, is how many installed dependencies are below each item in the flame graph? e.g. 128 for react-dates?

this number would at least tell you the maximum number of indirect dependencies contributed by that package, even if some of those are going to be shared by other packages, e.g. doesn't tell you how many packages would get removed by removing that package. (since other packages could have shared dependencies)

[JosephMaynard]

@mindplay-dk Thank you for the continued feedback.

Having thought about it, you were right again, the number of connections was more an implementation detail of the graphs than anything useful to actual users.

I spent the weekend on it and did a bit of reading, and the flame graph hierarchy is now built from a dominator tree instead. A bar's width is the number of packages that would leave node_modules if you deleted it, each counted exactly once, which I think is much closer to the question you were actually asking.

There is also a new treemap view (the same dominator maths, disk-usage style), which give an alternative overview of project dependencies. Hyperbolic got some updates too, it is still experimental, but I think it is a bit more useful now and certainly more pretty!

Browser back and forward now work while exploring too with the new hash router. Views, selections, and filters are mirrored into the URL, so you can retrace your steps or share a link into a specific view (assuming of course everyone has the same file).

Your comment about "how many packages would get removed by removing that package" stuck with me. Selecting a package now shows exactly that as a removal preview, i.e. what deleting it frees, what survives and who keeps it, and which dependents block removal.

I had previously been reluctant to show the package size information we collect, since on-disk size has no bearing on your shipped bundle after tree shaking and minification, but I figured it may be useful for your use case. It is in there now, measured from disk, with what I hope is a sufficient disclaimer that nobody will expect their bundled JS to come out 20 MB smaller.

All of this is in 1.2.0. If you get a chance to try it, I would be very interested to hear what you think!