4 ms·
I don’t quite follow the reasoning. You can reverse the argument: When one package breaks, then — all else being equal — more dependents are likely to be affect
by layer8 1y ago
I don’t quite follow the reasoning. You can reverse the argument: When one package breaks, then — all else being equal — more dependents are likely to be affected if it is a large package with many functions than if it is a tiny package with just one function.
What made the left-pad incident prominent is that the package had so many dependents. That’s due to how frequently its functionality is useful, not due to its size. And in general these are inversely correlated characteristics.
Yet another argument: If any given function breaks, then the affected dependents are invariant under the granularity of packaging. Exactly those dependents will break that make use of the given function, regardless of the packaging.
The one argument I could buy is that depending on a larger number of packages increases the likelihood of depending on unreliable maintainers. Still, in the case of left-pad that isn’t entirely convincing, since the maintainer in question maintained so many packages.
- baobabKoodaa 1y agoI specifically said in my post that I did not make the argument you think I made. Here is a copypaste of the part where I clarified that: > So we're not taking the same set of code as dependencies, slicing it into different number of slices, instead we're taking less code as dependencies.