> maintains hundreds of packages
> hundreds
How can a single human reasonably and responsably do this? This number alone demonstrates how sloppy and inept the Node.js community's practices are.
> maintains hundreds of packages
> hundreds
How can a single human reasonably and responsably do this? This number alone demonstrates how sloppy and inept the Node.js community's practices are.
Not to that degree.
Unix frequently espouses "do one thing", but how much "one thing" is is always open to interpretation.
And it's never been quite as small as e.g. left-pad. It's more something like `printf` or `cat`, which do "print a formatted string" and "concatenate files" as their "one thing", respectively.
Let me reiterate: The problem isn't "single responsibility", the problem is "single responsibility for half a thing".
The pieces are just too tiny, which leads to an explosion of packages, which leads to packages being badly maintained.
I think the big difference is that very few people set their systems to trust and receive updates of `cat` directly from the developers of `cat` (and same for all the other standard tiny utilities). Instead, they rely on a Linux distribution to vet the developers' code and to regularly pull in updates. Maybe there's room for a similar model of distributions vetting code in the npm ecosystem.
https://github.com/freebsd/freebsd/blob/master/bin/cat/cat.c
Also, cat is kind of an important primitive for building a functional system that uses files as one of its core abstractions. It makes total sense that it would (a) exist and (b) be well maintained by an authoritative and reliable source.
Left pad it is not.
Interestingly, the `raw_cat()` function is 37 lines long.
https://github.com/freebsd/freebsd/blob/e511976db9f51bae1a59...
Looking at the kernel itself you see a hierarchy where people are only responsible for small segments of the kernel.
Looking at a standard distro like Debian, which makes this easily available at https://www.debian.org/devel/people you'll see that most individuals are only responsible for a handfull of packages, with the bulk having a team responsible for them.
Not saying that I think maintaining hundreds sounds like a good idea, just trying to point out the misunderstanding :) .