[frutiger]

> Such is life in the npm world, unfortunately.

I don't really think npm is to blame in this specific case. It's merely acting as an index to a set of tarballs, e.g. the same way PyPI or crates.io do.

It would be fairer to point the blame at the ecosystem and mindset of developers of popular JavaScript libraries.

[lucideer]

I've recently been taking my time evaluating dependencies for a few small node projects, and I've actually found I've been impressed at how few dependencies are used by a subset of the Javascript package ecosystem.

I find, anecdotally, that rather than the broad spectrum you might expect, packages tend to either have a huge number of dependencies, or very few. Meaning if you do want to slim down your project's dependencies, it's usually simply a matter of identifying the whales and substituting/eliminating them with something saner.

Take for example two of the most popular package bundlers:

- parcel: direct dependencies: 59, total dependencies: 1575

- rollup: direct dependencies: 3, total dependencies: 9

[girvo]

Completely agreed. If auditibility of your dependency tree is something you're after, npmjs.com makes it pretty easy to find particular packages that also care about that, keeping your dependency list as small as possible.

The downside is that the most popular libraries and frameworks do not really do this; babel being a particularly egregious example, but I understand why they choose that path even if it isn't the choice I would make!

[sbr464]

It’s actually not that straightforward. A library could bundle their dependencies as part of their own build step/publish. They would appear to have zero/less dependencies, but really they just bundled them.

[lucideer]

Possible but I haven't seen a library that does this. Seems like a very unusual way to do things.

Something to worry about if it ever became prevalent I guess, but doesn't seem to be rn.