How do you tell your "baked" version is any good though? Doesn't that mean N days after colors.js ground zero you'll start picking up the bad colors.js since it's now baked for N days?

The "bad" colors.js existed for less than 24 hours before it was removed by NPM. Similarly the other recent malicious packages were detected and removed quickly.

The idea is that for maliciously published packages like this (both deliberately in this case, and also when the maintainer's account is hacked) that not all packages that depend on this dependency will need the same length of N. Some users will want to pick it up right away, but some very conservative applications may want N to be much longer. It's basically the idea that alpha/beta users can be the canaries, but those who don't want to take any risk can hold back. Right now, unless you've got a lock file, essentially everyone is pulling the latest released version whether they want to be conservative or not.

Ah, that was the piece I was missing. Basically we are relying on NPM to curate/remove obvious bad packages from the global registry within some timeframe (say, 3 days) and by lagging behind by 3 days you'll never pick up an obvious bad package.

Yes, but presumably it would have been discovered by then.

Seems like you would also want "and there isnt a release 2 days after it" fixing a regression. Starts to get tough :/