> It saddens me that everyone took this as a chance to attack tiny modules as the scapegoat.
Not really. For instance, I claim that too many dependencies is a bad thing
for some time already, left-pad farce being merely an example of why is that.
It takes some long-lived code to see the cost of adding a dependency, and
several such cases (and possibly deploying the code in different ways in
different environments) to realize it was paid due to having a dependency.
> There is a chance here for npm to try hard to come up with nice trust/security/immutability features to accomodate these new module dynamics better.
This new module dynamics feels like a constant fall, or maybe like running
before a locomotive that won't ever stop, so you need to keep running or be
run over. It doesn't look healthy.
> Not really. For instance, I claim that too many dependencies is a bad thing for some time already, left-pad farce being merely an example of why is that.
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. And actually, `kik` is almost the same example. "Luckily" nobody cared about kik.
I also claim that having many small dependencies is very different from having many large dependencies.
> It takes some long-lived code to see the cost of adding a dependency, and several such cases (and possibly deploying the code in different ways in different environments) to realize it was paid due to having a dependency.
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.
Example: once leftPad is performant and working, its done. You can just pin it. When is lodash done? Probably never.
> This new module dynamics feels like a constant fall, or maybe like running before a locomotive that won't ever stop, so you need to keep running or be run over. It doesn't look healthy.
And dependency hell also looked impossible before npm and commonjs brought a solution to the mainstream :) Lets see if they can solve the rest of the problems too.
> 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.
> 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.
Yes, lets scrap the entire thing just because we cannot deep-pin individual dependencies. How about adding support for deep-pinning individual dependencies instead?
> re-solved by PIP and gems
Afaik, those two don't solve the problem. If within project P, dependency A depends on C v1 and dependency B depends on C v2, they just can't resolve that conflict. Which is a non-starter for tiny modules.
Not really. For instance, I claim that too many dependencies is a bad thing for some time already, left-pad farce being merely an example of why is that.
It takes some long-lived code to see the cost of adding a dependency, and several such cases (and possibly deploying the code in different ways in different environments) to realize it was paid due to having a dependency.
> There is a chance here for npm to try hard to come up with nice trust/security/immutability features to accomodate these new module dynamics better.
This new module dynamics feels like a constant fall, or maybe like running before a locomotive that won't ever stop, so you need to keep running or be run over. It doesn't look healthy.