Number of dependencies are misconceived.

[jimmywarting]

One decision making in picking any dependency is also the number of sub dependencies it has. npmjs.org don't mention this in any meaningful way.

We all want the stack to be small, fast to download, exec fast, less JIT compiling and not have so many places where vulnerability can enter.
this is not taken into consideration when a developer looks at a npm package and thinking "grate, this only has one dependency" while in fact it has many sub-dependencies

taking standard-markdown as an example...

This is what i would like to see:

This makes you 2nd guessing if you really need "that" package cuz it went from 6 to 254 dependencies

a very large/deep dependency can take long time to load if you take out the bundler/npm & tree shaking out of the equation.
this playground only loads standardjs-markdown + a hole bunch of other things ending up with 3.8mb download

right now i'm very thankful for npmgraph existences

[ljharb]

The number of deps has no relation to “less JIT compiling” (nor is that something you can reliably ever optimize for).

Surfacing this kind of information defeats the point of dependencies imo - which is to serve as an abstraction. It shouldn’t matter whether one dep is large/complex and has zero deps of its own, or whether it’s got hundreds of deps composed in it (but is smaller and less complex in aggregate), except to encourage more dependency use, not less.

[MylesBorins]

hey @jimmywarting thanks for the suggestion.

I could see how have an idea of the full size of the tree would be useful in certain cases... you want to know not just direct dependencies but also transitive dependencies.

My concern with the proposed mock is that unless someone know exactly what that means it would be a confusing number. Fitting "dependencies" and "transitive dependencies" into the same line would also be a bit confusing.

To make matters even more confusing / fun... depending on your tree and if transitive dependencies have updated / changed at all the number of transitive dependencies is VERY dynamic and could change at any point... consistently calculating this for all packages on all page views to ensure that it is accurate seems... expensive.

Due simply to the dynamic nature of transitive deps I don't think that this is something that should be surfaced by default on the landing pages of packages.

Thoughts?

[jimmywarting]

hmm, get your point about dynamic numbers, seems like a both pro & con

My concern with the proposed mock is that unless someone know exactly what that means it would be a confusing number. Fitting "dependencies" and "transitive dependencies" into the same line would also be a bit confusing.

it was just a quick inline edit on the webpages devtool (just to demonstrate what i wanted to have) how it would actually present this was never really the issue.

[MylesBorins]

@jimmywarting keeping things up to do from the serverside would be extremely burdensome / expensive / error-prone. For now I don't think the team will be exploring this request, but thank you for the suggestion.