Nobody is asking for the madness of having proper-sized packages split into 100 smaller packages with zero advantages and actually a few disadvantages (difficult to audit, impossible to fork). This is what is being criticised here.
It would be perfectly fine to have a single `terminal-utils` package that contained all of this. And no, handlebar-helpers doesn't count.
> I see this general trend as a symptom of the inadequacy of JS to out-of-the-box address the tasks it's used for, which (as we note here) opens an outlet for spamming and security liabilities.
Two wrongs don't make a right. Package authors should not spam, regardless of the issues with of the ecosystem or language.
Tree-shaking can help at least keeping the build artefact small, but it doesn't help with the codebase during development.
Of course there is still a difference between fine-grained dependencies and things that shouldn't be dependencies in the first place.
Especially when most of those packages are almost never used by themselves, and are instead part of a meta-package with dozens of dependencies.
But I'm with you, this is ridiculous and auditability alone is reason enough to avoid it. Even if you were trying to make a case for composable packages this is absurd to the point that I wonder if it's self aware criticism of npm or an inside joke.
Precisely what? That's not one self-contained package I said is okay.