Instead of teasing, can you just tell us what the difference is between unpublishing N small packages versus one large package containing the same set of functionality?
When you develop software by gluing together 1000000 small packages, you now have 1000000 points of failure.
When you develop software by... you know, writing trivial things by yourself instead of downloading a package... you have maybe 100 points of failure instead of 1000000 points of failure.
Having 100 points of failure is better than having 1000000 points of failure.
Note that in this example you are writing trivial things by yourself instead of adding a package. 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.
2. Whether to take dependencies at all ("buy or build")
It's still not clear to me how taking a larger dependency (with things I might not need) is inherently better than taking smaller dependencies. That seems like a question of trade-offs. What if there's an issue or security hole in a portion of the larger dependency that I didn't even use? For example, that log4j LDAP debacle, what if that were broken down into smaller dependencies so that you didn't even have the LDAP thing if you weren't using it?
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.
I 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.
