If you're distributing software, that means that you need to verify the source each of the 1000 dependencies, check if the licence is appropriate, and verify that there aren't any current published vulnerabilities in the version that you're using.

Doing this bare minimum of due diligence is easy if you have 10 dependencies, but quite costly for a 1000.

I don't see how the number of dependencies is important here, instead of their size. You can trivially automate license checks.

The number is misleading anyway, because many "packaged" libraries that you would normally look at as a single module are split into individual modules for perf reasons.

Because you need to trust 1000 different people.

Again, it's not about the number of people, is it? You don't have 1000 top level dependencies, so you're not trusting 1000 entities. If you're really talking about people, companies that produce libraries have hundreds of employees - do you "trust" them all? No, what you're talking about is establishing a web of trust, and you can do that in JS as well. Use a framework, use a library that combines a set of tools together. There's nothing particularly different about JS in this regard - there are plenty of large-scale development shops(Google, Facebook, Mozilla, Yahoo, Netflix..) which offer code, alongside a healthy open source community. You choose what to use.

1000 transitive dependencies is not the same as a single dependency with 1000 employees. For one, I highly doubt each employee can `npm publish`.

Consider the destructiveness of someone malicious befriending the left-pad developer, taking the project over, and doing a malicious push.

I'd say the scale of the potential destruction in so many tiny, few-eyeballed modules is unique to the npm ecosystem for better or worse.

It's one of the security downsides of the ecosystem especially in the online casino space where I work. For example, getting an online casino's `npm ls` (full depth) would be a good place to start.

The scale of transitive deps we're talking about when compared to any other ecosystem is quite excessive, but also just how tiny many of those deps are.

> Consider the destructiveness of someone malicious befriending the left-pad developer, taking the project over, and doing a malicious push.

Not different from someone befriending a corporate employee and asking them to insert some malicious code into the codebase. You still rely on a web of trust - in the company's case, the code reviewers, in the open source example, the maintainers of the libraries that use left-pad. I don't think this argument really holds, I don't know what you're comparing it against that's different.

We'll have to agree to disagree if you see equivalence there.

Even the smallest transitive dependency in our largest dependency graph in the Java ecosystem isn't someone's 6-liner afternoon project.

I think the ease of publishing + ecosystem of small modules is a good thing, it just has what we consider an ecosystem-level security trade-off that matters for some applications.

The corporate employee is likely incentivized by a contractual obligation not to deliberately screw their employer over. There is a web of trust, sure, but don't pretend that it's somehow equivalent to betting that some rando on the internet doing whatever they feel like with their three line repo won't break your code.

1000 opportunities for semver to go wrong. And what happens if dependencies pin different versions of their dependencies? The code is duplicated in the JS bundle?

Both versions appear there, yes. Not ideal, but I'd be interested to hear what you regard as more optimal behavior in the context of a dependency graph like the one you assume.

(Dependency bloat can be a real thing, sure. But if I have to choose between adding a dependency on a solid, well-built module and spending the time to reinvent the same complex wheel all by myself, I'm going to pick the option that gets me more quickly to done, 100% of the time. I'm paid to bring business value, and while minimizing technical debt where it counts is a big part of that, spending unbounded time to satisfy my own peculiar notion of software perfectibility is most emphatically not.)