Sure, so you can represent the other far extreme. I certainly advocate for review, but we should be practical. No one reads all the code down to the proc to ensure nothing malicious is happening, and the average software dev wouldn't be able to understand something malicious at that level anyway. I could have used a more hyperbolic example than a practical one (have you read all the PHP source for the version you're on? Have you read all your PECL libraries? Those ones are okay but OSS in PHP is not? Why? Just because it's harder to read C, right?). Pretending we do review everything is disingenuous -- but we should do what we can. Review doesn't have to be reading lines of code, but it could be ensuring it comes from popular and trusted sources (part of my earlier comment).

It should be noted that your example was not bad source, so rigorously reviewing source code would not have helped. It was an unpublish event which was unexpected but is now differently handled by the package managers + registries.

Your example about php source, or any of the bundled extensions would be a valid point if they were maintained by one or two single developers.

As you say, it’s impossible to review everything.

But how many projects have been caught out by sudden changes to previously working dependencies? Either revoked code, malware inclusion, breaking changes, etc.

If your dependencies are versioned and go through a review like internal changes, it’s much easier to spot changes.

I agree that a trusted source is invaluable- my point is that (a) npm hasn’t shown itself to be that and (b) the “externalise all the things” approach pushed so heavily by the nodejs community means it’s not just your dependencies you need to worry about - it’s the crab-grass like tree of nested dependencies.