I wonder why npm doesn't block pre/postinstall scripts by default, which pnpm and Bun (and I imagine others) already do.

EDIT: oh I scrolled down a bit further and see you said the exact same thing in a top-level comment hahah, my bad

Isn't that what lockfiles are for? By default `npm i` downloads exactly the versions specified in your lockfile, and only resolves the latest versions matching the ranges specified in package.json if no lockfile exists. But CI/CD pipelines should definitely be using `npm ci` instead, which will only install packages from a lockfile and throws an error if it doesn't exist.

These days compromised packages are often detected automatically by software that scans all packages uploaded to npm like https://socket.dev or https://snyk.io. So I imagine it's still useful to have those services scan these packages first, before they go out to the masses.

Measures like this also aren't meant to be "final solutions" either, but stop-gaps. Slowing the spread can still be helpful when a large scale attack like this does occur. But I'm also not entirely sure how much that weighs against potentially slowing the discovery as well.

Ultimately this is still a repository problem and not a package manager one. These are merely band-aids. The responsibility lies with npm (the repository) to implement proper solutions here.

> The responsibility lies with

there's apparently an npm RFC from 2022 proposing a similar (but potentially slightly better?) solution https://github.com/npm/rfcs/issues/646

I've used sendme a few times after coming across Iroh on Bluesky. It's honestly great. Just Works™, very fast, supports files and folders, resumable transfers, one sender to many receivers, and has fast relays as a fallback when a direct connection truly isn't possible, and it will actually tell you whether you have a direct connection or are using a relay (unlike others like Magic Wormhole or Croc from my experience).