But from the average programmer's perspective this is clearly something they want. 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.

No. What programmers want are solutions to problems.

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.

I get the ridiculousness of those tiny packages. On the other hand I also hate to have my codebase bloated by some kitchen-sink "util" package of which I'll use about 0.1% functionality. (while, if I were really strict, I'd also have to audit and track the remaining 99.9% of the code.)

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.

There is a sane middle ground between tiny and bloated, though. I don't see how using a false dichotomy justifies the issues we're complaining about.

Especially when most of those packages are almost never used by themselves, and are instead part of a meta-package with dozens of dependencies.

Having one package for all of these — that's okay and something people might want. Intentionally spreading it out to 26 "packages" — just no.

But the package that's generating all these numbers, handlebar-helpers, does precisely that. Sure, the spammer gets internet points, but those don't matter.

Security matters. Performance matters. Hackability/forkability matters. This kind of practice reduces security and auditability of systems, and makes projects harder to hack and fork.

From a security perspective what issues do you see besides auditability? It seems like the surface area for supply chain attacks is expanded needlessly by these types of shenanigans but I'm not sure how that translates to concrete impact to a project. I suppose resources required to scan and detect a package takeover are needlessly consumed but that's more upstream/centralized.

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.

> does precisely that

Precisely what? That's not one self-contained package I said is okay.

ansi-red is not a difficiency of JS. It's just stupid. It the equivalent of a package called add2 and another called add3. No language I know of has that built in and if it did it would arguably be a bad sign