Good luck with nr 1 in the js ecosystem and its 30k dependencies 50 branches deep per package

As an outsider looking in as I don't deal with NPM on a daily basis, the 30k dependencies going 50 branches deep seems to be the real problem here. Code reuse is an admiral goal but this seems absurd. I have no idea if these numbers are correct or exaggerations but from my limited time working with NPM a year or two ago it seems like it's a definite problem.

I'm in the C ecosystem mostly. Is one NPM package the equivalent of one object file? Can NPM packages call internal functions for their dependencies instead of relying so heavily on bringing in so many external ones? I guess it's a problem either way, internal dependencies having bugs vs supply chain attacks like these. Doesn't bringing in so many dependencies lead to a lot of dead code and much larger codebases then necessary?

	▲	marcosdumay 16 minutes ago \| parent [-]
		> Is one NPM package the equivalent of one object file? No. The closest thing to a package (on almost every language) is an entire library. > Can NPM packages call internal functions for their dependencies instead of relying so heavily on bringing in so many external ones? Yes, they can. They just don't do it. > Doesn't bringing in so many dependencies lead to a lot of dead code and much larger codebases then necessary? There aren't many unecessary dependencies, because the number of direct dependencies on each package is reasonable (on the order of 10). And you don't get a lot of unecessary code because the point of tiny libraries is to only import what you need. Dead code is not the problem, instead the JS mentality evolved that way to minimize dead code. The problem is that dead code is actually not that much of an issue, but dependency management is.