Upcoming breaking changes for NPM v12

The mood was less excitement than relief. People read this as npm finally catching up to what pnpm already did by default. Several commenters tied the change directly to the old CERT report on arbitrary script execution during package install and to the recent run of real-world attacks that made the issue impossible to ignore. The practical read is that npm is closing one of its most obvious holes, very late, because install-time code execution has been abused over and over. The useful nuance is that the new model is more targeted than a single global switch. Commenters noticed the allowlist can be written into package.json and pinned per package and version, which makes org-wide policy more workable and keeps approval scoped to specific dependencies instead of reopening the whole system. That said, nobody treated this as a complete fix. If a dependency still runs as part of your build toolchain or at application runtime, you are still trusting code you pulled from the registry. The change mostly removes the worst case where code executes during install before a developer or CI system has even decided it should run anything at all. A second thread pushed on what npm still is not doing. People wanted a default delay before brand-new package versions can be installed, so security scanners and humans get a day to catch malicious releases. pnpm already moved in that direction. Others argued this is the kind of defense that blocks more attacks in practice than stronger account auth alone, because many compromises are detected within a day or two. The overall landing point was clear: v12 is a real improvement, but it is basic hygiene, not a solved supply-chain story.