pnpm 11 Release Candidate: ESM Distribution, Supply Chain Defaults and a New Store Format

The pnpm team has released version 11 as a release candidate, marking a significant evolution in the popular JavaScript package manager's architecture and security posture. The update introduces a SQLite-backed store index, hardened supply chain protections, isolated global installs, and a pure ESM distribution model that requires Node.js v22 or later.

Security-First Defaults and Supply Chain Protection

Following a series of high-profile supply chain incidents in the npm ecosystem, pnpm 11 implements stricter security defaults. The minimumReleaseAge setting now defaults to 1 day, creating what some have called a "dependency cooldown" period where newly published package versions are not immediately resolved. This approach aims to give the community time to identify and flag malicious packages before they can be installed.

The blockExoticSubdeps option is enabled by default, preventing packages from installing dependencies outside their specified ranges. These changes have sparked debate within the developer community about the trade-offs between security and development velocity.

"The people who will benefit from a cooldown weren't reviewing updates anyway. Without the cooldown they would just be one more malware victim"

Some developers argue that these delays could slow critical security patches, while others contend that the protection outweighs the inconvenience. The pnpm team has positioned these defaults as essential safeguards for production environments.

Build Script Consolidation and Configuration Changes

Build script handling has been significantly simplified in pnpm 11. Multiple configuration options including onlyBuiltDependencies, neverBuiltDependencies, and ignoredBuiltDependencies have been consolidated into a single allowBuilds setting. The strictDepBuilds option is now enabled by default, providing additional protection against malicious build scripts.

Configuration management has also been streamlined. pnpm no longer reads configuration from the pnpm field in package.json or from npm_config_ environment variables. The global configuration file has moved to YAML format, and several legacy options including allowNonAppliedPatches, ignorePatchFailures, and useNodeVersion have been removed.

Performance Enhancements and New Features

The release introduces several performance optimizations. HTTP requests now use undici with Happy Eyeballs for faster connection establishment. Package downloads are pre-allocated, and metadata caching uses NDJSON format for improved efficiency. Direct-to-store writes eliminate the staging directory, speeding up installation times.

New commands expand pnpm's capabilities:

• pnpm ci for clean installations
• pnpm sbom for Software Bill of Materials generation
• pnpm clean for clearing the store
• pnpm peers check for peer dependency validation
• pnpm runtime set for runtime management

Short aliases pn and pnx provide quicker access to common operations.

Global Install Isolation

A major architectural change affects global package management. Each pnpm add -g package now receives its own isolated directory with separate package.json, node_modules, and lockfile. The global virtual store is enabled by default for pnpm dlx and global packages, though regular projects can opt into this feature.

Node.js Compatibility and ESM Distribution

pnpm 11 drops support for Node.js versions 18, 19, 20, and 21, requiring Node.js v22 or later. The package manager is now distributed as pure ESM, aligning with modern JavaScript ecosystem standards. A compatibility matrix is available in the updated installation documentation.

Community Response and Industry Context

The release has generated significant discussion on platforms like Hacker News. Some developers advocate for pnpm over npm due to its security features, claiming that "PNPM 10.x shutdown a lot of these attack vectors" and that "NPM is too insecure for production CLI usage." Others push back, arguing that npm remains sufficiently secure for most use cases.

Compared to competitors, pnpm 11 maintains its advantages of isolated node_modules by default, content-addressable storage, and first-class monorepo support. The addition of SBOM generation via pnpm sbom and stricter build script handling extends pnpm's lead in security features where Yarn still lacks parity.

Migration and Availability

Developers can try pnpm 11 today using pnpm self-update next-11. Migration guidance is available in the pnpm 11.x documentation and the v11 tracking discussion. The release candidate status indicates that while the core functionality is stable, some edge cases may still be addressed before the final release.

As the JavaScript ecosystem continues to grapple with supply chain security challenges, pnpm 11 represents a significant step toward more secure package management practices, albeit with trade-offs that the community continues to debate.