# npm Just Stopped Trusting Your Dependencies, and That Is a Good Thing > For fifteen years, npm install meant silently running code from hundreds of strangers. That default is dead. The quiet npm warn line in your terminal is the biggest shift in JavaScript dependency handling in a decade, and here is what it actually means. **Published:** 2026-06-26 **Tags:** Web Development, JavaScript, Node.js, Security, Supply Chain --- For fifteen years, typing `npm install` meant silently running code from hundreds of strangers, and trusting every one of them. That era is ending. The quiet `npm warn` line buried in your terminal output is not a bug report. It is npm telling you the default has flipped: from _trust everything_ to _trust nothing_. This is the biggest change in how JavaScript handles dependencies in a decade. Most teams will only notice when a pipeline breaks one morning for no reason they can see. So before that happens to you, here is what is actually changing, and why it is long overdue. ## The End of "Install Equals Execute" When you run `npm install`, packages can ship lifecycle scripts: `preinstall`, `install`, and `postinstall`. These run automatically, on your machine, with your permissions, the moment the package lands in `node_modules`. No prompt. No review. No questions. That behavior was never a bug. It was the design. Native modules use it to compile, tools use it to download binaries, and frameworks use it to wire up git hooks. Convenient, and for fifteen years, simply how things worked. The problem is the math. A modern project pulls in hundreds or thousands of transitive dependencies. Every single one of them, including packages you have never heard of and never chose, gets to run arbitrary code on your laptop and in your CI runner the instant you install. You are not trusting your dependencies. You are trusting your dependencies' dependencies' dependencies, all the way down. GitHub, which owns npm, has now named this for what it is: the single largest code-execution surface in the npm ecosystem. And in npm v12, estimated for July 2026, they are closing it. Here is the part npm's announcement quietly skips: it is not breaking new ground. It is catching up. pnpm flipped this exact default back in early 2025 with its v10 release, and both Yarn and Bun already block dependency install scripts out of the box. npm, the ecosystem's default package manager, is the _last_ of the major tools to do it. That is not a knock on the change. It is the clearest evidence of how overdue it was. ## What the Warning Is Really Telling You If you are on npm 11.16.0 or newer, you have already seen the signal. After an install, npm prints warnings and an end-of-install summary naming any dependency that ships install scripts you have not reviewed. Right now, that is advisory. The scripts still run. Nothing breaks. It is easy to scroll past, and most people do. That is the trap. The warning is not noise to be silenced. It is a countdown. In v12, the setting that governs all of this, `allowScripts`, defaults to off. At that point `npm install` will no longer run `preinstall`, `install`, or `postinstall` from your dependencies unless you have explicitly allowed them. Two sibling changes land alongside it: git dependencies and remote-tarball dependencies stop resolving by default too, closing related ways that untrusted code could sneak in. The line you have been ignoring for months is the only heads-up you get before the default changes underneath you. ## Why This Is the Right Call It is tempting to read this as npm making your life harder. It is the opposite. This change exists because the old default was actively dangerous, and attackers had figured that out. Install scripts are the perfect delivery mechanism for a supply chain attack. Compromise one popular package, or one of its obscure dependencies, push a malicious `postinstall`, and you get code execution on every machine that installs anything downstream. Developer laptops. CI runners with deployment credentials. Production build servers. The npm ecosystem has watched exactly this play out, repeatedly, with self-propagating worms that harvest tokens and spread to the next maintainer's packages. You cannot audit thousands of transitive dependencies by hand. Nobody can. So the only real defense is to flip the default: code does not get to run just because it showed up in `node_modules`. It runs because you decided it should. That is not paranoia. That is the same principle behind lockfiles, subresource integrity, and least-privilege access. Trust should be granted on purpose, not assumed by default. ## What It Means for How You Work For most projects, the practical cost is small and one-time. A handful of packages genuinely need install scripts: native modules that compile on install, image and build tools that fetch a binary, browser automation libraries that download a browser, git-hook managers. You review that short list, decide which ones you trust, and record your decision. After that, those run and nothing else does. The mental model is what actually shifts. Until now, a dependency was trusted the moment you added it. Going forward, adding a dependency and trusting it to execute code are two separate decisions. Your approved list becomes a real artifact, committed alongside your lockfile, reviewed in pull requests, and meaningful when it changes. A new package suddenly asking to run an install script is no longer invisible. It is a line in a diff that a human has to approve. That is a healthier relationship with code you did not write. You are not blocking yourself from using native modules or build tools. You are making the moment of trust explicit, visible, and revocable. ## The One Thing to Do Before July You do not need to wait for v12 to find out whether this affects you. Upgrade to npm 11.16.0 or later, run a normal install, and read the warnings. They will tell you, today, exactly which of your dependencies expect to run install scripts. That list is your entire migration. Review it, approve what you trust, commit the result, and you are ready before the default ever changes. The teams that get caught out in July will be the ones who spent the next few weeks dismissing a warning they assumed was harmless. The teams that sail through will be the ones who treated it as what it is: npm finally telling you the truth about what `npm install` has been doing all along. ## The Bottom Line Dependencies are not your code. They are code you borrowed from strangers, and for fifteen years npm ran all of it without asking. That default made sense in a smaller, more trusting ecosystem. It does not make sense anymore. Default-deny on install scripts is not npm being difficult. It is npm growing up, and dragging the rest of us toward a saner posture in the process. The warning in your terminal is not in your way. It is on your side. Stop scrolling past it.