3 ms·
It used to be that adding library dependencies to a project had a lot of fraction, and if you were writing a library yourself, then imposing indirect dependenci
by jimrandomh 4y ago
It used to be that adding library dependencies to a project had a lot of fraction, and if you were writing a library yourself, then imposing indirect dependencies on users was something you'd try fairly hard to avoid.
Then npm came, along with some ideology about code-reuse, and the friction went away. But the friction was serving an important function: if adding a library is annoying, you'll add a small number of large libraries rather than a large number of small ones, and you avoid getting an ecosystem where major libraries have hundreds of tiny dependencies. This is important because the friction of adding a dependency is only a small portion of its true cost: the main cost is that you're trusting too many different developers and developers' computers.
- ElevenLathe 4y agoThis is a good framing of it. Can we keep the benefits of automatic dependency resolution while adding some other, artificial deterrent? What if NPM hosted packages for free if they have less than five (or whatever number) of transitive dependencies, but above that charged some number per additional one? Even if it were a small amount, this might put significant downward pressure on the size of dependency trees.