This is not possible under the npm/js paradigm of massive module dependency trees. You'll get a module and it will have 10 dependencies and each of those 10 dependencies will each have 5 dependencies. Three of those at the 4th level was an infected eslint package.

They've learned precious little since left-pad.

Right! that's what I thought this is left-pad all over again.

Although left-pad was really just a disgruntled publisher... this involves a malicious third party.

My suggestion in fixing the later would be to enforce 2FA for publishing of packages that have so many dependents.

Award a badge to a release when it is published with 2FA. So for LTS releases they can be verified as manually published. This will impact package consumers decision making process, on whether or not to include a dependency into their package.json.

The node package ecosystem is not "designed" to work this way. Everybody is encouraged to use many single purpose packages. The production app I work on at work has over 1000 dependencies. Almost all of them are transitive. (We have maybe 20-30 specified dependencies.)

It's possible to use NPM that way too, I don't think it's "designed" to work in any specific way it just installs what you tell it to.

It's important to be pragmatic about blindly-installed and unreviewed 3rd-party code that can read our ENV.

Those 20 - 30 modules you like could probably each achieve a significant reduction in their dependencies and you probably could too by exploring their alternatives.

The culture of the Node.js ecosystem is to split things into many small packages, so there is no alternative dependencies with a fewer number of dependencies themselves. (This is drastically different than some ecosystems like Go, where dependencies are practically discouraged.) We try to avoid using obscure packages anyway, so even if there was, we'd be choosing between the popular and well tested package to one that was less popular and tested but had less dependencies. This is probably not a tradeoff we'd be willing to make without a lot of trust in the less popular package.

I have never seen NodeJS (or any other) developers advocating to blindly include third-party code in their applications. I think what you are describing is just a side-effect of not considering the ramifications which only works until NPM (or any package manager) starts being exploited.

At least in my experience it's surprisingly difficult to find alternative packages that don't rely on all sorts of (often gratuitous) other dependencies.