pnpm 10.0.0 Blocks Lifecycle Scripts by Default

The big news in Node package managers this week in pnpm’s version 10.0.0 release, which includes a number of breaking changes. One major update that rattled a few users is that pnpm is now blocking lifecycle scripts and will use an allow list of built dependencies by default.

Lifecycle scripts of dependencies are not executed during installation by default! This is a breaking change aimed at increasing security. In order to allow lifecycle scripts of specific dependencies, they should be listed in the pnpm.onlyBuiltDependencies field of package.json.

Lifecycle scripts include preinstall, install, postinstall, prepublish, prepare, etc. that developers define in the scripts section of their package.json file, which are automatically executed by the package manager.

pnpm maintainer Zoltan Kochan said this move is in direct response to the recent Rspack supply chain attack, which distributed cryptomining malware that was executed via a postinstall script that ran automatically when the package was installed. Kochan created a poll on X following the incident, asking if pnpm should be blocking these scripts by default.

“After each of such incidents we get a tsunami of requests to do something in order to make it harder to run lifecycle scripts,” Kochan said. “I created a poll on X and looks like so far most are in favor to block scripts by default. But I really don't think we have a choice here as Bun already blocks the scripts, so it will claim that it is more secure than pnpm.”

Kochan also posted the poll on Bluesky and GitHub. Yarn maintainers also responded, indicating they are considering this as well.

Although the majority of respondents are in favor of blocking lifecycle scripts, the update was somewhat controversial in that it fundamentally changes expectations for developers relying on consistent behavior across package managers.

“Wasn't pnpm an npm drop-in replacement about efficiency and speed? Now it sadly seems to try really hard to be incompatible with npm,” web developer Katja Lutz commented on changes in pnpm 10. “It’s expected that lifecycle scripts are executed. If you want to disable them for security, why not have a ‘—ignore-scripts’ flag like npm?”

Others embrace the change but recognize that it may require an uncomfortable transition for users.

“I'm strongly in favor of blocking post-install scripts by default,” pnpm contributor Brandon Cheng commented on the PR.

“This is a change that will have a painful adjustment period for our users, but I believe in ~1 year everyone will look back and be thankful we made it. It's nuts that a [pnpm|yarn|npm] install can run arbitrary code in the first place.

“To state the apparent, the downside is that we'll have a few users confused when certain dependencies no longer work without further user actions. While this doesn't address every attack vector, closing a major design flaw is worth some unfortunate friction and surprising errors on our users. When you consider the systems that could be compromised both now and in the future if we don't make this change, the value of this change is clear.”

Cheng suggested reducing surprises by:

• Introducing a command like pnpm approve-scripts to review and approve post-install scripts interactively, with a prompt after pnpm install if any scripts need attention.
• Adding a short explanation field in package.json for scripts, similar to smartphone app permission requests, to provide context for users deciding whether to allow or deny them.

Cheng acknowledged that his second suggestion would be a major hurdle, as it would be difficult to get the ecosystem to buy into these changes.

Kochan pointed out that pnpm has an info message that it prints “The following dependencies have build scripts that were ignored,” and offered to move the message to the end, make it more prominent, and add instructions about how to allow scripts for those dependencies.

Multiple package managers are moving to reduce the threat of supply chain attacks in response to growing incidents like the Rspack malware exploit, which have highlighted vulnerabilities in lifecycle script execution. These changes aim to improve security and rebuild trust in the ecosystem, though they often come with trade-offs in developer convenience and compatibility.

In addition to blocking lifecycle scripts by default, pnpm 10 introduces several notable updates. It enhances security by adopting SHA256 for hashing algorithms, ensuring improved consistency and protection. The behavior of the pnpm link command has also been updated to add overrides directly to the root package.json, affecting all projects in a workspace or enabling global linking from a package's directory.

Check out the changelog for more details on everything included in pnpm 10.0.0.