Last time I wrote a Firefox extension, the code was manually reviewed before being officially published on addons.mozilla.org (it's there as experimental release with big warning bars while it sits in queue for code review).
To publish an Android app, I need to verify my name by paying Google some money ($25?) and my code has to pass some automated checks.
It seems like anyone can publish just about anything anonymously on npm. That model has upsides, but it's not exactly state-of-the art in terms of QA (though you could argue whether QA is the right term here).
Your QA teams are looking up every entry in your package.json files, your Maven poms, your Gemfiles, your requirements.txt files? They're making sure that something that builds completely cleanly and shows no external errors doesn't have a typo in it?
That's a pretty big straw man you wrote there, to imply that getting rid of not-all errors is no better than not getting rid of any errors at all.
In fact, GNU/Linux distros with even minimal QA will disallow network access during builds. Also we do in fact manually audit quite a lot of stuff to make sure this sort of bullshit doesn't get uploaded to the archives.
My QA team, upon a request to add a package called "crossenv" to the npm repo, would say "this is suspiciously similar to the existing cross-env package. Request denied." Alas, npm has no such team.
A problem that exists because there was no QA to start... Instead we get "awesome" lists of "curated" packages on github, which does nothing to solve the problem.
Half a million, is that all?
Levels of QA exist. As pointed out by https://news.ycombinator.com/item?id=14905660 it would take very little to require something like a bug report that's then had various levels signed off on.
