pnpm 10.32 adds an --all flag to pnpm approve-builds for approving all pending builds without interactive prompts.

Minor Changes​

--all Flag for pnpm approve-builds​

Added --all flag to pnpm approve-builds that approves all pending builds without interactive prompts #10136.

pnpm approve-builds --all

Patch Changes​

• Reverted change related to setting explicitly the npm config file path, which caused regressions.
• Reverted fix related to lockfile-include-tarball-url. Fixes #10915.

pnpm 10.31 preserves comments and formatting when updating pnpm-workspace.yaml, and includes numerous bug fixes.

Minor Changes​

Preserving Comments in pnpm-workspace.yaml​

When pnpm updates the pnpm-workspace.yaml, comments, string formatting, and whitespace will be preserved.

Patch Changes​

• Added -F as a short alias for the --filter option in the help output.
• Handle undefined pkgSnapshot in pnpm why -r #10700.
• Fix headless install not being used when a project has an injected self-referencing file: dependency that resolves to link: in the lockfile.
• Fixed a race condition when multiple worker threads import the same package to the global virtual store concurrently. The rename operation now tolerates ENOTEMPTY/EEXIST errors if another thread already completed the import.
• When lockfile-include-tarball-url is set to false, tarball URLs are now always excluded from the lockfile. Previously, tarball URLs could still appear for packages hosted under non-standard URLs #6667.
• Fixed optimisticRepeatInstall skipping install when overrides, packageExtensions, ignoredOptionalDependencies, patchedDependencies, or peersSuffixMaxLength changed.
• Fixed pnpm patch-commit failing with "unable to access '/.config/git/attributes': Permission denied" error in environments where HOME is unset or non-standard (Docker containers, CI systems) #6537.
• Fix pnpm why -r --parseable missing dependents when multiple workspace packages share the same dependency #8100.
• Fix link-workspace-packages=true incorrectly linking workspace packages when the requested version doesn't match the workspace package's version #10173.
• Fixed pnpm update --interactive table breaking with long version strings by dynamically calculating column widths instead of using hardcoded values #10316.
• The parameter set by the --allow-build flag is written to allowBuilds.
• Fix a bug in which specifying filter on pnpm-workspace.yaml would cause pnpm to not detect any projects.
• Print help message on running pnpm dlx without arguments and exit.

pnpm 10.30 redesigns pnpm why to show a reverse dependency tree, making it much easier to understand why a package is installed.

Minor Changes​

Reverse Dependency Tree in pnpm why​

pnpm why now shows a reverse dependency tree. The searched package appears at the root with its dependents as branches, walking back to workspace roots. This replaces the previous forward-tree output which was noisy and hard to read for deeply nested dependencies.

Patch Changes​

• Optimize pnpm why and pnpm list performance in workspaces with many importers by sharing the dependency graph and materialization cache across all importers instead of rebuilding them independently for each one #10596.

pnpm 10.29 adds catalog: protocol support to pnpm dlx, allows configuring auditLevel in pnpm-workspace.yaml, supports a bare workspace: specifier, and includes several bug fixes.

Minor Changes​

catalog: Protocol in pnpm dlx​

The pnpm dlx / pnpx command now supports the catalog: protocol, allowing you to reference versions defined in your workspace catalogs:

pnpm dlx shx@catalog:

auditLevel Setting​

auditLevel can now be configured in the pnpm-workspace.yaml file, so you don't need to pass --audit-level on every pnpm audit invocation #10540:

auditLevel: high

Bare workspace: Protocol​

A bare workspace: specifier without a version range is now supported. It is treated as workspace:* and resolves to the concrete version during publish #10436:

{
  "dependencies": {
    "foo": "workspace:"
  }
}

Patch Changes​

• Fixed an out-of-memory error in pnpm list (and pnpm why) on large dependency graphs by replacing the recursive tree builder with a two-phase approach: a BFS dependency graph followed by cached tree materialization. Duplicate subtrees are now deduplicated in the output #10586.
• Fixed allowBuilds not working when set via .pnpmfile.cjs #10516.
• When enableGlobalVirtualStore is set, pnpm deploy now ignores it and always creates a localized virtual store within the deploy directory to keep it self-contained.
• Fixed minimumReleaseAgeExclude not being respected by pnpm dlx #10338.
• Fixed pnpm list --json returning incorrect paths when using global virtual store #10187.
• Fixed pnpm store path and pnpm store status using workspace root for path resolution when storeDir is relative #10290.
• Fixed catalogMode: strict writing the literal string catalog: to pnpm-workspace.yaml instead of the resolved version specifier when re-adding an existing catalog dependency #10176.
• Skip local file: protocol dependencies during pnpm fetch, fixing Docker builds when local directory dependencies are not available #10460.
• Fixed pnpm audit --json to respect the --audit-level setting for both exit code and output filtering #10540.
• Updated tar to version 7.5.7 to fix a security vulnerability (CVE-2026-24842).
• Fixed pnpm audit --fix replacing reference overrides (e.g. $foo) with concrete versions #10325.
• Fixed shamefullyHoist set via updateConfig in .pnpmfile.cjs not being converted to publicHoistPattern #10271.
• pnpm help now correctly reports if the currently running pnpm CLI is bundled with Node.js #10561.
• Added a warning when the current directory contains the PATH delimiter character, which can break node_modules/.bin path injection #10457.
• Fixed the documentation URL shown in pnpm completion --help to point to the correct page #10281.

pnpm 10.28 introduces a new beforePacking hook to customize package.json at publish time, improves filtered install performance, and includes several bug fixes.

Minor Changes​

beforePacking Hook​

Added support for a new hook called beforePacking that allows you to customize the package.json contents at publish time #3816.

This hook is called just before creating the tarball when running pnpm pack or pnpm publish. It gives you the opportunity to modify the package manifest that will be included in the published package without affecting your local package.json file.

Example usage in .pnpmfile.cjs:

module.exports = {
  hooks: {
    beforePacking(pkg) {
      // Remove development-only fields
      delete pkg.devDependencies
      delete pkg.scripts
      // Add publication metadata
      pkg.publishedAt = new Date().toISOString()
      return pkg
    }
  }
}

See the .pnpmfile.cjs documentation for more details.

Filtered Install Performance​

In some cases, a filtered install (i.e. pnpm install --filter ...) was slower than running pnpm install without any filter arguments. This performance regression is now fixed. Filtered installs should be as fast or faster than a full install #10408.

Patch Changes​

• Do not add a symlink to the project into the store's project registry if the store is in a subdirectory of the project #10411.
• It should be possible to declare the requiredScripts setting in pnpm-workspace.yaml #10261.

pnpm 10.27 adds a new setting to ignore trust policy checks for older package versions, introduces a project registry for global virtual store pruning, and includes several bug fixes.

Minor Changes​

trustPolicyIgnoreAfter​

Adding trustPolicyIgnoreAfter allows you to ignore trust policy checks for packages published more than a specified time ago #10352.

Global Virtual Store Improvements​

Added project registry for global virtual store prune support.

Projects using the store are now registered via symlinks in {storeDir}/v10/projects/. This enables pnpm store prune to track which packages are still in use by active projects and safely remove unused packages from the global virtual store.

Semi-breaking. Changed the location of unscoped packages in the virtual global store. They will now be stored under a directory named @ to maintain a uniform 4-level directory depth.

Added mark-and-sweep garbage collection for global virtual store.

pnpm store prune now removes unused packages from the global virtual store's links/ directory. The algorithm:

1. Scans all registered projects for symlinks pointing to the store
2. Walks transitive dependencies to mark reachable packages
3. Removes any package directories not marked as reachable

This includes support for workspace monorepos - all node_modules directories within a project (including those in workspace packages) are scanned.

Patch Changes​

• Throw an error if the value of the tokenHelper or <url>:tokenHelper setting contains an environment variable.
• Git dependencies with build scripts should respect the dangerouslyAllowAllBuilds settings #10376.
• Skip the package manager check when running with --global and a project packageManager is configured, and warn that the check is skipped.
• pnpm store prune should not fail if the dlx cache directory has files, not only directories #10384
• Fixed a bug (#9759) where pnpm add would incorrectly modify a catalog entry in pnpm-workspace.yaml to its exact version.

2025 has been a transformative year for pnpm. While our primary focus was redefining the security model of package management, we also delivered significant improvements in performance and developer experience.

From blocking lifecycle scripts by default to introducing a global virtual store, here is a look back at the major features shipped in 2025.

使い方​

According to download stats pnpm was downloaded 2 times more than in 2024!

Redesign of the Homepage​

You may have noticed that we have redesigned our homepage! This redesign was made possible by our most prominent sponsor, Bit.cloud.

The new homepage is now built with Bit components and much of the work was done using Bit's AI agent: Hope AI. We even have our own design system now.

Presentation at JSNation​

This year was a huge milestone for me personally as I had my first ever live presentation at a big international conference: JSNation in June in Amsterdam. I would like to thank the JSNation team for this great opportunity!

I was pleasantly surprised how well known pnpm is in the community and how many people use it at their work!

My presentation was about config dependencies and you can see the recording here.

機能のハイライト​

Now, let’s dive into the most significant changes shipped in pnpm v10 throughout 2025.

Security by Default​

The most significant shift this year was pnpm's move to "Security by Default." In pnpm v10.0, we stopped implicitly trusting installed packages.

Blocking Lifecycle Scripts (v10.0)​

For years, pnpm install meant trusting the entire dependency tree to execute arbitrary code. In v10, we turned this off. pnpm no longer runs preinstall or postinstall scripts by default, eliminating a massive class of supply chain attack vectors.

To refine this control, we introduced allowBuilds in v10.26, replacing the earlier onlyBuiltDependencies with a more flexible configuration:

allowBuilds:
  esbuild: true
  # Only allow specific versions
  nx@21.6.4: true

Defense in Depth (v10.16 & v10.21)​

We didn't stop at scripts. We added layers of defense to catch malicious packages before they even reach your disk:

• minimumReleaseAge: Blocks "zero-day" releases (e.g., packages younger than 24 hours), giving the community time to flag malicious updates.
• trustPolicy: no-downgrade: Prevents installing updates that have weaker provenance than previous versions (e.g., a version published without CI/CD verification).
• blockExoticSubdeps: Prevents trusted dependencies from pulling in transitive dependencies from untrusted sources.

Global Virtual Store (v10.12)​

One of pnpm's original innovations was the content-addressable store, which saved disk space by deduplicating files. In v10.12, we took this a step further with the Global Virtual Store.

Previously, projects had their own node_modules structure. With enableGlobalVirtualStore: true, pnpm can now link dependencies from a central location on disk directly into your project. This means:

1. Massive Disk Savings: Identical dependency graphs are shared across projects.
2. Faster Installs: If you have 10 projects using react@19, pnpm only needs to link it once globally.

Native JSR Support (v10.9)​

We embraced the new JSR registry with native support. You can now install packages directly from JSR using the jsr: protocol:

pnpm add jsr:@std/collections

This maps correctly in package.json and handles the unique resolution rules of JSR packages seamlessly alongside your npm dependencies.

Config Dependencies (v10.0)​

For monorepos and complex setups, we introduced Config Dependencies. This feature allows you to share and centralize pnpm configuration—like hooks, patches, and build permissions—across multiple projects.

Config dependencies are installed into node_modules/.pnpm-config before the main dependency graph is resolved. This means you can use them to:

• Share .pnpmfile.cjs hooks across repositories.
• Centralize patch files for patchedDependencies.
• Maintain a shared list of packages that are allowed to execute build scripts for allowBuilds.

configDependencies:
  pnpm-plugin-my-company: "1.0.0+sha512-..."

This ensures your pnpm configuration is versioned, consistent, and available exactly when the package manager needs it.

Automatic JavaScript Runtime Management (v10.14 & v10.21)​

We have supported Node.js runtime management for a while now. In 2025, we extended this to support other runtimes like Deno and Bun.

You can now specify the required runtime in package.json via devEngines.runtime:

{
  "devEngines": {
    "runtime": {
      "name": "node",
      "version": "24.6.0"
    }
  }
}

pnpm will automatically download and use that specific version of the runtime for running scripts in that project. This makes "Works on my machine" a thing of the past—everyone on the team uses the exact same runtime, managed entirely by pnpm.

Looking Ahead​

We have already started working on pnpm v11.0, which has some noticeable performance improvements. The global virtual store will not yet be enabled by default. We will work on bug fixes and missing features to potentially enable it by default in a future major release.

pnpm 10.26 introduces stricter security defaults for git-hosted dependencies, adds allowBuilds for granular script permissions, and includes a new setting to block exotic transitive dependencies.

Minor Changes​

Stricter Git Dependency Security​

Semi-breaking. Git-hosted dependencies are now blocked from running prepare scripts during installation unless they are explicitly allowed in onlyBuiltDependencies (or allowBuilds) #10288. This change prevents malicious code execution from untrusted git repositories.

allowBuilds​

Added a new setting allowBuilds which provides a flexible way to manage build scripts. It accepts a map of package matchers to explicitly allow (true) or disallow (false) script execution. This replaces onlyBuiltDependencies and ignoredBuiltDependencies as the preferred configuration method #10311.

例:

allowBuilds:
  esbuild: true
  core-js: false
  nx@21.6.4 || 21.6.5: true

blockExoticSubdeps​

Added a new setting blockExoticSubdeps to improve supply chain security. When set to true, it prevents the resolution of exotic protocols (like git+ssh: or direct https: tarballs) in transitive dependencies. Only direct dependencies are allowed to use exotic sources #10265.

Integrity Hash for HTTP Tarballs​

Semi-breaking. pnpm now computes the integrity hash for HTTP tarball dependencies when fetching them and stores it in the lockfile. This ensures that servers cannot serve altered content on subsequent installs without detection #10287.

pnpm pack --dry-run​

Added support for --dry-run to the pack command. This allows you to verify which files would be included in the tarball without actually creating it #10301.

Patch Changes​

• Show deprecation in table/list formats when latest version is deprecated #8658.
• Remove the injectWorkspacePackages setting from the lockfile on the deploy command #10294.
• Normalize the tarball URLs before saving them to the lockfile #10273.
• Fix URL normalization for redirected immutable dependencies #10197.

pnpm 10.25 improves certificate handling, adds a bare pnpm init, and ships several quality-of-life fixes.

Minor Changes​

Per-registry certificates​

You can now load inline certificates from the cert, ca, and key settings for specific registry URLs (for example, //registry.example.com/:ca=-----BEGIN CERTIFICATE-----...). Previously, pnpm only respected the certfile, cafile, and keyfile entries. This aligns pnpm with npm's .npmrc behavior #10230.

pnpm init --bare​

Added a --bare flag to pnpm init for creating a package.json with only the required fields #10226.

Patch Changes​

• Improved reporting of ignored dependency scripts #10276.
• pnpm install now builds any dependencies that were added to onlyBuiltDependencies but have not run their builds yet #10256.
• pnpm publish -r --force will publish even if the version already exists in the registry, matching the intent of the flag #10272.
• Avoid ERR_PNPM_MISSING_TIME errors when a package excluded from trust policy checks lacks the time field in its metadata.

We got lucky with Shai-Hulud 2.0.

In November 2025, a self-replicating npm worm compromised 796 packages with 132 million monthly downloads. The attack used preinstall scripts to steal credentials, install persistent backdoors, and in some cases wipe entire developer environments. We weren't affected—not because we had robust defenses, but because we didn't run npm install or npm update during the attack window.

Luck isn't a security strategy.

Who We Are​

I'm Ryan Sobol, Principal Software Engineer at the Seattle Times. We've been using npm as our default package manager for years, with some brief experimentation with Yarn that never gained traction. Now we're piloting pnpm specifically for its client-side security controls that complement the registry-level improvements npm has been rolling out.

Trust is paramount for news organizations, especially these days. A supply chain compromise could expose customer data, employee credentials, production infrastructure, and source code—all things that could take weeks to recover from and potentially require breach notifications to our readers. We understand how expensive these incidents can be in both time and money. That's a path we don't want to go down.

Despite the organizational inertia that comes with sticking to npm, we think pnpm has a real chance here. It's a true drop-in replacement—same commands, same workflows, same registry. That makes the transition achievable in a way previous alternatives weren't.

This isn't a polished case study. It's a real-world data point from a team that's just starting to figure out supply chain security. The challenges we're encountering and how we're thinking about these controls might be useful as you consider implementing them yourself.

Why Client-Side Controls Matter​

npm has made tremendous progress on supply chain security. Trusted publishing, provenance attestations, and granular access tokens are all significant improvements that make it substantially harder to publish malicious packages after compromising maintainer accounts.

But here's the gap: these registry improvements protect the publishing side. They don't prevent consuming malicious packages.

When you run npm install or npm update, lifecycle scripts (e.g., preinstall and postinstall) execute arbitrary code from the internet with full developer privileges—before the package has been evaluated for safety. These scripts can access your credentials (npm, GitHub, AWS, databases), your source code, your cloud infrastructure, and your entire filesystem.

This is the fundamental vulnerability that attacks like Shai-Hulud exploit. Even with these registry improvements, if a legitimate maintainer's account is compromised, attackers can publish a version with malicious lifecycle scripts that execute immediately upon installation—before the community detects the compromise.

That's why we felt we needed defense on both sides: npm's improvements make it harder to publish malicious packages; pnpm's client-side controls make it harder to consume them. These approaches are complementary, not competitive. pnpm uses npm's registry and benefits from all of npm's security improvements while adding an additional layer of protection on the client side.

This is defense-in-depth.

The Three Layers We're Using​

For our pilot, we're using three pnpm security controls that work together. Each control addresses a different attack vector, and each has escape hatches for legitimate exceptions. We knew going in that we'd need those exceptions—the real world is messy.

Control 1: Lifecycle Script Management​

One of the main reasons we considered pnpm was learning that it blocks lifecycle scripts by default. Unlike other package managers, it doesn't implicitly trust and execute arbitrary code from packages.

In practice, when a package has preinstall or postinstall scripts, pnpm blocks them but installation continues with a warning. This already provides significant protection—malicious scripts won't execute without you explicitly allowing them. However, we were concerned that warnings would be too easy to ignore, especially since installation appears to succeed. We wanted stricter control with strictDepBuilds: true:

strictDepBuilds: true

onlyBuiltDependencies:
  - package-with-necessary-build-scripts

ignoredBuiltDependencies:
  - package-with-unnecessary-build-scripts

By "necessary," we mean packages that genuinely need their lifecycle scripts to function—things like native extensions that compile from source or database drivers that link against platform-specific libraries. By "unnecessary," we mean scripts that are optional optimizations or setup steps that don't affect whether the package functions in our use case.

With strictDepBuilds: true, installation fails immediately when it encounters lifecycle scripts, forcing us to:

1. Identify which packages have lifecycle scripts—pnpm tells you exactly which ones
2. Research what each script does, which can be as easy as feeding the self-contained preinstall or postinstall script into a generative AI for interpretation
3. Use human judgment to make a conscious, documented decision about whether to allow or block it

For our team, this ensures we're making deliberate choices upfront rather than potentially discovering issues later.

Note: The pnpm team is considering making strictDepBuilds: true the default behavior in v11, and is also exploring clearer naming for the allow/deny syntax based on feedback from teams implementing these controls in practice.

Control 2: Release Cooldown​

This control blocks installation of package versions published within a cooldown period. The idea is to give the community time to detect and remove malicious packages before they reach your environment.

minimumReleaseAge: <duration-in-minutes>

minimumReleaseAgeExclude:
  - package-with-critical-hotfix@1.2.3

Our mindset shift: We had to retrain ourselves to stop thinking "newest is best." What we're learning is that from a supply chain security perspective, that's not always the case—slightly older can often be safer. A package that's been available for a period of time gives the community and security researchers time to detect potential issues.

Looking at recent attacks, malicious packages have been detected and removed in varying timeframes. The September 2025 npm supply chain attack that compromised debug, chalk, and 16 other packages saw removal within about 2.5 hours, while Shai-Hulud 2.0 (November 2025) took about 12 hours. Every attack is different and every recovery timeline will vary, but the appropriate cooldown period depends on your organization's risk tolerance—it could be measured in hours, days, or weeks. Either way, a cooldown period would have blocked these attacks.

The trade-off we accepted: Given the scale of our organization and our priorities, we're not always on the absolute latest versions of packages—despite best efforts. So this cooldown policy aligns more with our reality than it disrupts it. When we genuinely need a newer version (critical security patches, breaking bugs), we can temporarily exempt it after review.

Control 3: Trust Policy​

This control blocks installation when a package version has weaker authentication than previously published versions—often a sign that an attacker compromised maintainer credentials and published from their own machine instead of the official CI/CD pipeline.

trustPolicy: no-downgrade

trustPolicyExclude:
  - package-that-migrated-cicd@1.2.3

How it works: npm tracks three trust levels for published packages (strongest to weakest):

1. Trusted Publisher: Published via GitHub Actions with OIDC tokens and npm provenance
2. Provenance: Signed attestation from a CI/CD system
3. No Trust Evidence: Published with username/password or token authentication

If a newer version has weaker authentication than an older version, installation fails. For example, if v1.0.0 was published with Trusted Publisher but v1.0.1 was published with basic auth, pnpm blocks v1.0.1.

In the s1ngularity attack in August 2025, attackers compromised maintainer credentials and published malicious versions from their own machines. Because they didn't have CI/CD access, the malicious versions had no provenance—a clear trust downgrade. This control would have blocked installation.

When trust downgrades might be legitimate: New maintainer who hasn't set up provenance yet, CI/CD system migration, emergency hotfix published manually while CI/CD was down. In these cases, we'd investigate why the trust level decreased, verify it's safe, then add to trustPolicyExclude.

Note: This feature was added to pnpm in November 2025 and is quite new. We're still learning how often legitimate trust downgrades occur in practice.

How They Work Together: The React Example​

We don't see any of these controls as a silver bullet. They work as layers of defense—when we need to make an exception for one control, the other layers continue protecting us.

Let's look at a real scenario: the critical React vulnerability disclosed in December 2025.

This was a serious security issue that required immediate patching. Normally, our release cooldown would prevent us from installing a package version published so recently. But this was a critical security patch—we couldn't wait.

Here's how the layered defense would work in this scenario:

What you'd do: Add the specific React version to minimumReleaseAgeExclude after reviewing the vulnerability disclosure and verifying the patch was legitimate.

What still protects you:

• Lifecycle Script Management is still active—if an attacker had injected malicious lifecycle scripts into the React patch, they would be blocked (React normally has no lifecycle scripts, so any scripts would be immediately suspicious)
• Trust Policy is still active—if an attacker had compromised React's publishing credentials and pushed a malicious "patch" from their own machine, the trust downgrade would be blocked

This is why we think exceptions are expected and okay. You make a conscious, documented decision to bypass one control for a legitimate reason, but you still have robust protection from the other layers. No single point of failure.

This is what defense-in-depth looks like in practice for us.

Our Pilot Experience​

We implemented all three security controls in one of our backend services as a proof of concept. Total setup time: a few hours to research, understand, and define our approach.

During setup, pnpm identified three packages with lifecycle scripts:

• esbuild: Optimizes CLI tool startup by milliseconds—not needed since we only use the JavaScript API
• @firebase/util: Auto-configures client SDK—not needed since we only use the server SDK
• protobufjs: Checks version schema compatibility—not needed since it's a transitive dependency

We researched what each script did (reading documentation and feeding the scripts to AI for interpretation), determined none were necessary for our use case, and blocked them. Zero impact on functionality.

That was it. A few hours of initial investment for ongoing protection against Shai-Hulud-style attacks.

What the friction feels like: These controls create friction by design—and for us, that's a feature, not a bug. The friction forces conscious decisions about what code runs in our environment rather than implicitly trusting everything. When new dependencies have scripts, we anticipate it will take around 15 minutes to review and document the decision.

We expect that the friction will become more intuitive with practice as we get more familiar with the process.

What We're Learning​

A few things we've learned from our pilot:

The defense-in-depth model actually works. Having multiple layers on the client side—plus the benefits from npm's publishing-side improvements—means we can be pragmatic about exceptions. When we need to bypass one control for a legitimate reason, the others are still protecting us. This removes the anxiety of making exceptions—they're not security failures, they're the system working as designed.

The mental model takes time. There's a learning curve to thinking "security-first" rather than "convenience-first." But once the mental model clicks—that slightly older packages are safer, that explicit decisions are better than implicit trust—the workflow feels natural.

These controls are practical for mid-sized teams. We're not a large tech company with a dedicated security team. We're a mid-sized news media organization with limited engineering resources. If we can implement these controls successfully, they're accessible to most teams.

We're still learning. The threat landscape evolves, and our approach will too. The trust policy feature is only a few weeks old, and we don't yet know how often legitimate trust downgrades will occur in practice. We're planning to expand these controls to other codebases in the near future, which will give us more data on how they scale with applications with different dependency graphs.

For Other Teams Considering This​

If you're considering pnpm's security controls, here's what worked for us:

Start with one project. Piloting on a single codebase first let us get comfortable with the workflow, understand the friction points, and build confidence before considering a broader rollout.

Plan for exceptions upfront. Go in expecting you'll need exceptions for lifecycle scripts (packages that need compilation), release cooldowns (critical security patches), and trust downgrades (CI/CD migrations). This isn't failure—it's how the system is designed to work.

Use strictDepBuilds: true from day one. Relying on warnings felt too risky for us. We wanted installation to fail immediately and force the decision. This prevents packages from potentially misbehaving later and ensures deliberate choices.

Document every exception. Write down why you allowed a lifecycle script or exempted a package. This creates an audit trail, helps future team members understand the reasoning, and makes it easy to clean up exceptions later.

Trust the layers. When you make an exception for one control, remember the other two are still protecting you. The defense-in-depth model gives you room to be pragmatic.

Share Your Experience​

We'd love to hear from other teams implementing these controls or considering them. What's working? What's challenging? What have you learned? Join the conversation in the pnpm GitHub Discussions or share your experiences on social media—we're all learning together.

Thank You​

Thanks to the pnpm team for building these controls and for the thoughtful way they've approached making them both powerful and practical. And thanks for inviting us to share our story.

The work you're doing matters. These controls provide real protection that complements npm's registry improvements. Together, they give teams like ours a fighting chance against increasingly sophisticated supply chain attacks.

Ryan Sobol is a Principal Software Engineer at the Seattle Times, where he works on mobile and web development, cloud infrastructure, and developer tooling. The views expressed here are his own and based on the Seattle Times' pilot implementation of pnpm's security controls.

pnpm now scales network concurrency automatically on high-core machines and ships several reliability fixes.

Minor Changes​

Adaptive network concurrency​

Network concurrency now scales automatically between 16 and 64 based on the number of pnpm workers (workers × 3). This increases throughput on machines with many CPU cores while keeping resource usage predictable on smaller setups #10068.

Patch Changes​

• trustPolicy now ignores trust evidences from prerelease versions when you install a non-prerelease version, so a trusted prerelease cannot block installing a stable release that lacks trust evidence.
• Handle ENOENT errors thrown by fs.linkSync(), which can occur in containerized environments (OverlayFS) instead of EXDEV. pnpm now gracefully falls back to fs.copyFileSync() in these cases #10217.
• Reverted: pnpm self-update downloading pnpm from the configured npm registry #10205.
• Packages that don't have a package.json file (like Node.js) are no longer reimported from the store on every install. pnpm now checks an additional file to verify the package in node_modules.
• Correctly read auth tokens for URLs that contain underscores #17.

Added --lockfile-only option to pnpm list and various improvements to pnpm self-update.

Minor Changes​

pnpm list --lockfile-only​

Added --lockfile-only option to pnpm list #10020.

When specified, pnpm list will read package information from the lockfile instead of checking the actual node_modules directory. This is useful for quickly inspecting what would be installed without requiring a full installation.

Patch Changes​

• pnpm self-update should download pnpm from the configured npm registry #10205.
• pnpm self-update should always install the non-executable pnpm package (pnpm in the registry) and never the @pnpm/exe package, when installing v11 or newer. We currently cannot ship @pnpm/exe as pkg doesn't work with ESM #10190.
• Node.js runtime is not added to "dependencies" on pnpm add, if there's a engines.runtime setting declared in package.json #10209.
• The installation should fail if an optional dependency cannot be installed due to a trust policy check failure #10208.
• pnpm list and pnpm why now display npm: protocol for aliased packages (e.g., foo npm:is-odd@3.0.1) #8660.
• Don't add an extra slash to the Node.js mirror URL #10204.
• pnpm store prune should not fail if the store contains Node.js packages #10131.

Added support for excluding packages from trust policy and overriding the engines field on publish.

Minor Changes​

Trust policy exclusions​

Added support for trustPolicyExclude.

You can now list one or more specific packages or versions that pnpm should allow to install, even if those packages don't satisfy the trust policy requirement. 例:

trustPolicy: no-downgrade
trustPolicyExclude:
  - chokidar@4.0.3
  - webpack@4.47.0 || 5.102.1

Related issue: #10164

Override engines field on publish​

Allow to override the engines field on publish by the publishConfig.engines field.

This allows you to specify different engine requirements for your published package than what you use during development.

Patch Changes​

• Don't crash when two processes of pnpm are hardlinking the contents of a directory to the same destination simultaneously #10179.

Added support for Node.js runtime installation for dependencies and a setting for configuring trust policy.

Minor Changes​

Node.js runtime installation for dependencies​

Added support for automatic Node.js runtime installation for dependencies. pnpm will now install the Node.js version required by a dependency if that dependency declares a Node.js runtime in the engines.runtime field. 例:

{
"engines": {
  "runtime": {
    "name": "node",
    "version": "^24.11.0",
    "onFail": "download"
  }
}
}

If the package with the Node.js runtime dependency is a CLI app, pnpm will bind the CLI app to the required Node.js version. This ensures that, regardless of the globally installed Node.js instance, the CLI will use the compatible version of Node.js.

If the package has a postinstall script, that script will be executed using the specified Node.js version.

Related PR: #10141

Trust policy​

Added a new setting: trustPolicy.

When set to no-downgrade, pnpm will fail if a package's trust level has decreased compared to previous releases. For example, if a package was previously published by a trusted publisher but now only has provenance or no trust evidence, installation will fail. This helps prevent installing potentially compromised versions.

Related issue: #8889.

Other features​

• Added support for pnpm config get globalconfig to retrieve the global config file path #9977.

Patch Changes​

• When a user runs pnpm update on a dependency that is not directly listed in package.json, none of the direct dependencies should be updated #10155.
• Don't crash when two processes of pnpm are hardlinking the contents of a directory to the same destination simultaneously #10160.
• Setting gitBranchLockfile and related settings via pnpm-workspace.yaml should work #9651.

This release adds a --all flag for the pnpm help command to print all commands.

Minor Changes​

pnpm help --all​

Added support for --all option in pnpm help to list all commands #8628.

Patch Changes​

• When the latest version doesn't satisfy the maturity requirement configured by minimumReleaseAge, pick the highest version that is mature enough, even if it has a different major version #10100.
• create command should not verify patch info.
• Set managePackageManagerVersions to false, when switching to a different version of pnpm CLI, in order to avoid subsequent switches #10063.

This release adds version-scoped controls to two settings: onlyBuiltDependencies and minimumReleaseAgeExclude.

Minor Changes​

Versions in onlyBuiltDependencies​

You can now allow specific versions of dependencies to run postinstall scripts. onlyBuiltDependencies accepts package names with exact versions (and disjunctions via ||). 例:

onlyBuiltDependencies:
- nx@21.6.4 || 21.6.5
- esbuild@0.25.1

Related PR: #10104.

Versions in minimumReleaseAgeExclude​

Added support for exact versions in minimumReleaseAgeExclude. This lets you opt specific versions out of the maturity window enforced by minimumReleaseAge.

You can list one or more specific versions that pnpm should allow to install, even if those versions don’t satisfy the maturity requirement set by minimumReleaseAge. 例:

minimumReleaseAge: 1440
minimumReleaseAgeExclude:
- nx@21.6.5
- webpack@4.47.0 || 5.102.1

Related issue: #9985.

Minor Changes​

Added network performance monitoring to pnpm by implementing warnings for slow network requests, including both metadata fetches and tarball downloads.

Added configuration options for warning thresholds: fetchWarnTimeoutMs and fetchMinSpeedKiBps. Warning messages are displayed when requests exceed time thresholds or fall below speed minimums

Related PR: #10025.

Patch Changes​

• Retry filesystem operations on EAGAIN errors #9959.
• Outdated command respects minimumReleaseAge configuration #10030.
• Correctly apply the cleanupUnusedCatalogs configuration when removing dependent packages.
• Don't fail with a meaningless error when scriptShell is set to false #8748.
• pnpm dlx should not fail when minimumReleaseAge is set #10037.

Minor Changes​

The minimumReleaseAgeExclude setting now supports patterns.

例：

minimumReleaseAge: 1440
minimumReleaseAgeExclude:
- "@eslint/*"

Related PR: #9984.

Patch Changes​

• Don't ignore the minimumReleaseAge check, when the package is requested by exact version and the packument is loaded from cache #9978.
• When minimumReleaseAge is set and the active version under a dist-tag is not mature enough, do not downgrade to a prerelease version in case the original version wasn't a prerelease one #9979.

Minor Changes​

New setting for delayed dependency updates​

There have been several incidents recently where popular packages were successfully attacked. To reduce the risk of installing a compromised version, we are introducing a new setting that delays the installation of newly released dependencies. In most cases, such attacks are discovered quickly and the malicious versions are removed from the registry within an hour.

The new setting is called minimumReleaseAge. It specifies the number of minutes that must pass after a version is published before pnpm will install it. For example, setting minimumReleaseAge: 1440 ensures that only packages released at least one day ago can be installed.

If you set minimumReleaseAge but need to disable this restriction for certain dependencies, you can list them under the minimumReleaseAgeExclude setting. For instance, with the following configuration pnpm will always install the latest version of webpack, regardless of its release time:

minimumReleaseAgeExclude:
- webpack

Related issue: #9921.

Advanced dependency filtering with finder functions​

Added support for finders.

In the past, pnpm list and pnpm why could only search for dependencies by name (and optionally version). 例:

pnpm why minimist

prints the chain of dependencies to any installed instance of minimist:

verdaccio 5.20.1
├─┬ handlebars 4.7.7
│ └── minimist 1.2.8
└─┬ mv 2.1.1
└─┬ mkdirp 0.5.6
  └── minimist 1.2.8

What if we want to search by other properties of a dependency, not just its name? For instance, find all packages that have react@17 in their peer dependencies?

This is now possible with "finder functions". Finder functions can be declared in .pnpmfile.cjs and invoked with the --find-by=<function name> flag when running pnpm list or pnpm why.

Let's say we want to find any dependencies that have React 17 in peer dependencies. We can add this finder to our .pnpmfile.cjs:

module.exports = {
finders: {
  react17: (ctx) => {
    return ctx.readManifest().peerDependencies?.react === "^17.0.0";
  },
},
};

Now we can use this finder function by running:

pnpm why --find-by=react17

pnpm will find all dependencies that have this React in peer dependencies and print their exact locations in the dependency graph.

@apollo/client 4.0.4
├── @graphql-typed-document-node/core 3.2.0
└── graphql-tag 2.12.6

It is also possible to print out some additional information in the output by returning a string from the finder. For example, with the following finder:

module.exports = {
finders: {
  react17: (ctx) => {
    const manifest = ctx.readManifest();
    if (manifest.peerDependencies?.react === "^17.0.0") {
      return `license: ${manifest.license}`;
    }
    return false;
  },
},
};

Every matched package will also print out the license from its package.json:

@apollo/client 4.0.4
├── @graphql-typed-document-node/core 3.2.0
│   license: MIT
└── graphql-tag 2.12.6
  license: MIT

Related PR: #9946.

Patch Changes​

• Fix deprecation warning printed when executing pnpm with Node.js 24 #9529.
• Throw an error if nodeVersion is not set to an exact semver version #9934.
• pnpm publish should be able to publish a .tar.gz file #9927.
• Canceling a running process with Ctrl-C should make pnpm run return a non-zero exit code #9626.

Minor Changes​

New setting for catalogs​

Added the cleanupUnusedCatalogs configuration. When set to true, pnpm will remove unused catalog entries during installation #9793.

Config dependency improvement​

pnpm will now automatically load pnpmfiles from config dependencies that are named @*/pnpm-plugin-* #9780.

Changes to the config get/set commands​

• pnpm config get now prints an INI string for an object value #9797.

• pnpm config get now accepts property paths.

  例:

  pnpm config get catalog.react
  pnpm config get .catalog.react
  pnpm config get 'packageExtensions["@babel/parser"].peerDependencies["@babel/types"]'
  

  pnpm config set now accepts dot-leading or subscripted keys.

  例:

  pnpm config set .ignoreScripts true
  

• pnpm config get --json now prints a JSON serialization of config value, and pnpm config set --json now parses the input value as JSON.

Patch Changes​

• Semi-breaking. When automatically installing missing peer dependencies, prefer versions that are already present in the direct dependencies of the root workspace package #9835.
• When executing the pnpm create command, must verify whether the node version is supported even if a cache already exists #9775.
• When making requests for the non-abbreviated packument, add */* to the Accept header to avoid getting a 406 error on AWS CodeArtifact #9862.
• The standalone exe version of pnpm works with glibc 2.26 again #9734.
• Fix a regression in which pnpm dlx pkg --help doesn't pass --help to pkg #9823.