> I claim that left-pad is an example of a malicious actor + a system that doesn't protect from that, not of the failing of small modules. It is mainly that, t

> I claim that left-pad is an example of a malicious actor + a system that doesn't protect from that, not of the failing of small modules. It is mainly that, this is right. But small modules make such a shitstorm more probable, simply because there are many more of them. > And actually, `kik` is almost the same example. "Luckily" nobody cared about kik. Do you believe it won't happen in the future? The more modules, the more likely it is. And project with JavaScript modules has an order or two of magnitudes more modules than in other languages. > I also claim that having many small dependencies is very different from having many large dependencies. Of course, but that's not what everybody talks about. It's many small modules vs. only several big ones. > It also takes some experience with small modules to see they are not like large modules at all, and you cannot apply the same thinking to them. But you can't apply different thinking to small modules, because you don't just use small modules, you use big ones as well, and those are in no way distinguishable except with the amount of code. > Example: once leftPad is performant and working, its done. You can just pin it. When is lodash done? Probably never. Oh, if it only was that easy. You don't control all the instances of left-pad you include (because indirect dependencies), so pinning it in your project is far from enough. > And dependency hell also looked impossible before npm and commonjs brought a solution to the mainstream :) Oh really? I thought it was solved dozen years earlier with various package managers in Linux distributions, and then re-solved by PIP and gems, and only after that comes npm.