The concern with left-pad isn't just that someone can break the build pipeline, it's that the author could just as easily have decided to push malicious code. By the time npm could react to that, your code base could already be compromised.

Each additional dependency you add is another vector for a supply chain attack. If you keep your dependencies to the large libraries (say, use lodash instead of a hundred tiny libraries), there are at least fewer people in your supply chain. But if you are depending on left-pad for its 10 lines of code (that still managed to have bugs), how many other random tiny dependencies did you bring in? How many individuals are in your supply chain? All it takes is for one of them to go rogue.

(Version pinning can help, but npm's default behavior is to accept minor version upgrades instead of pinning to the exact version that was live when you installed it. Lock files usually just get updated and recommitted without very much thought, so they don't help much either.)

> Except that the philosophy is beautiful and extremely useful due to composability

The philosophy is beautiful on the surface, which is exactly how far beauty extends.

Write some load-bearing software using a litany of software all connected by pipes throwing untyped text streams around to various handles. If you do this, and you do not experience problems due to composability, one of the following is true: 1) you aren't doing real work, 2) your software exists in an environment which never changes, which is very rare for most people (meaning that you have fixed your environment enough to wallpaper over problems with composability.)

statically compiled stuff and strongly typed data is the only way to longevity that is worth the time you need to put in to a system that must work.

> The philosophy itself is solid.

For some things, yes. For ad-hoc stuff, composability is amazing. Once in awhile I need to use a wrench to fix my car, and I have a whole array of wrenches to accommodate most needs I have with that car. I would never drive the car with a wrench still in place holding something together, and that's what the Unix philosophy promotes: take all these small tools which each do their thing and create some larger "grander-purpose" software with them.

That works if you need to do a one-time (or at least infrequent) analysis of some raw text, but I have learned over and over to not rely on the passing of plain text between programs for anything that you need to work later on. Something always changes which breaks it. Always. Maybe not for a year, but some update happens which subtly changes the output of a command which breaks stuff down the line.

With typed data checking and compiled applications (the opposite of passing untyped text between individual tools) I can easily account for errors before they happen, and rely on tests which exercise these things, and gain significant performance improvements over piped single-purpose tools, in less time overall.