[PeterisP]

A quantitative difference - in other programming languages you usually use a very limited number of dependencies, and the organization can follow every individual dependency that's used in production, knowing which versions you are using and tracking and monitoring their releases/notifications/changelogs as part of their software inventory. Like, a random quite large project that I recall had 10 dependencies from three vendors, two of those being Apache foundation and Oracle, and you can track and maintain those dependencies in the exact same manner as you track the OS and database system (and their versions/updates/patches) which the product is using.

This becomes difficult for node.js ecosystem simply due to the large quantity of those dependencies.

In many other cases you are only using dependencies that are considered to be verified and monitored/patched by others e.g. those included in LTS release of your OS; and you can make a statement that you will be using only dependencies that are being actively maintained including security fix backporting to the major release which you are using - and you check for that by verifying (and periodically re-verifying) the process and maintainers of each and every third party package you're using. Again, not practical when there's something importing things like left-pad.

[dncornholio]

Sure but this problem is not mutually exclusive to npm.

Python has pip, Rust has crates, Ruby has gems..

The fact that other languages have fewer dependencies, is (imo) probably because there aren't many dependencies uberhaupt?

My argument by the way, is that many dependencies is a feature, not a bug. And the developer probably looked at you like that because he thinks you have no trust in his ability to pick dependencies..

[m0zg]

Folks who publish stuff to PIP had the good sense to not require a hundred different other dependencies for each module they publish there. So it is tractable to just go through your entire transitive closure and ensure you're not including something you don't want.

And also, just because something is "hard" is not an excuse to just ignore it. NPM devs should be more aware of this issue, and make design decisions that improve the situation, such as, for example, not including a dep just to use a single function (the dep, by the way, might pull in 10 other deps, each of which could pull in some more). DRY is not a religious maxim, it's OK to do it to reduce "bushiness" and improve the predictability of the dependency graph.

[PeterisP]

The primary difference with other languages is not the availability of features - in general, pretty much every major language has almost all what you might need - but the differences in bundling. Many other languages have larger standard libraries, so things that might be "yet another dependency" in npm would be part of the standard distribution in other languages; and there are different approaches to bundling, as the same thing that might be dozens of dependencies in npm would be distributed and maintained as a single large package elsewhere.