This update for pnpm fixes the following issues:
Changes in pnpm:
update to 10.22.0:
Added support for trustPolicyExclude #10164. 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. For example:
trustPolicy: no-downgrade trustPolicyExclude: - chokidar@4.0.3 - webpack@4.47.0 || 5.102.1
Allow to override the engines field on publish by the publishConfig.engines field.
update to 10.21.0:
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" field. For example:
{ "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
Added a new setting: trustPolicy. When set to no-downgrade, pnpm will fail installation if a package’s trust level has decreased compared to previous releases — for example, if it was previously published by a trusted publisher but now only has provenance or no trust evidence. This helps prevent installing potentially compromised versions of a package. Related issue: #8889.
Added support for pnpm config get globalconfig to retrieve the global config file path #9977.
update to 10.20.0:
update to 10.19.0:
You can now allow specific versions of dependencies to run postinstall scripts. onlyBuiltDependencies now accepts package names with lists of trusted versions. For example: Related PR: #10104.
onlyBuiltDependencies: - nx@21.6.4 || 21.6.5 - esbuild@0.25.1
Added support for exact versions in minimumReleaseAgeExclude #9985. You can now 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. For example:
minimumReleaseAge: 1440 minimumReleaseAgeExclude: - nx@21.6.5 - webpack@4.47.0 || 5.102.1
update to 10.18.3:
update to 10.18.2:
update to 10.18.1:
update to 10.18.0:
update to 10.17.1:
update to 10.17:
The minimumReleaseAgeExclude setting now supports patterns. For instance:
minimumReleaseAge: 1440 minimumReleaseAgeExclude:
update to 10.16.1:
update to 10.16:
Minor Changes
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
Added support for finders #9946. In the past, pnpm list and pnpm why could only search for dependencies by name (and optionally version). For example:
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= 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
Patch Changes
update to 10.15.1:
update to 10.15.0:
update to 10.14.0:
Added support for JavaScript runtime installation (Related PR: #9755.) Declare Node.js, Deno, or Bun in devEngines.runtime (inside package.json) and let pnpm download and pin it automatically. Usage example:
{ "devEngines": { "runtime": { "name": "node", "version": "^24.4.0", "onFail": "download" // we only support the "download" value for now } } } How it works:
Add --cpu, --libc, and --os to pnpm install, pnpm add, and pnpm dlx to customize supportedArchitectures via the CLI #7510.
update to 10.13.1:
update to 10.13.0:
update to 10.12.4:
update to 10.12.3:
update to 10.12.2:
update to 10.12.1 (10.2.0 was yanked):
update to 10.11.1:
update to 10.11.0:
pnpm audit --ignore-unfixable Provide a list of CVE's to ignore those specifically, even if they have a resolution. pnpm audit --ignore=CVE-2021-1234 --ignore=CVE-2021-5678
update to 10.10.0:
update to 10.9.0:
udate to 10.8.1:
update to 10.8:
Minor Changes Experimental. A new hook is supported for updating configuration settings. The hook can be provided via .pnpmfile.cjs. For example:
module.exports = {
hooks: {
updateConfig: (config) => ({
...config,
nodeLinker: "hoisted",
}),
},
};
Now you can use the pnpm add command with the --config flag to install new configurational dependencies #9377.
Patch Changes
update to 10.7.1:
update to 10.7:
pnpm config get and list also show settings set in pnpm-workspace.yaml files #9316.
It should be possible to use env variables in pnpm-workspace.yaml setting names and value.
Add an ability to patch dependencies by version ranges. Exact versions override version ranges, which in turn override name-only patches. Version range * is the same as name-only, except that patch application failure will not be ignored. For example:
patchedDependencies: foo: patches/foo-1.patch foo@^2.0.0: patches/foo-2.patch foo@2.1.0: patches/foo-3.patch
The above configuration would apply patches/foo-3.patch to foo@2.1.0, patches/foo-2.patch to all foo versions which satisfy ^2.0.0 except 2.1.0, and patches/foo-1.patch to the remaining foo versions. [!WARNING] The version ranges should not overlap. If you want to specialize a sub range, make sure to exclude it from the other keys. For example:
patchedDependencies: # the specialized sub range 'foo@2.2.0-2.8.0': patches/foo.2.2.0-2.8.0.patch # the more general patch, excluding the sub range above 'foo@>=2.0.0 <2.2.0 || >2.8.0': 'patches/foo.gte2.patch
In most cases, however, it's sufficient to just define an exact version to override the range.
pnpm config set --location=project saves the setting to a pnpm-workspace.yaml file if no .npmrc file is present in the directory #9316.
Rename pnpm.allowNonAppliedPatches to pnpm.allowUnusedPatches. The old name is still supported but it would print a deprecation warning message.
Add pnpm.ignorePatchFailures to manage whether pnpm would ignore patch application failures.
update to 10.6.5:
update to 10.6.4:
update to 10.6.3:
update to 10.6.2:
update to 10.6.1:
update to 10.6.0:
pnpm-workspace.yaml can now hold all the settings that .npmrc accepts. The settings should use camelCase #9211. pnpm-workspace.yaml example:
verifyDepsBeforeRun: install optimisticRepeatInstall: true publicHoistPattern: - "types" - "!@types/react"
Projects using a file: dependency on a local tarball file (i.e. .tgz, .tar.gz, .tar) will see a performance improvement during installation. Previously, using a file: dependency on a tarball caused the lockfile resolution step to always run. The lockfile will now be considered up-to-date if the tarball is unchanged.
update to 10.5.2:
update to 10.5.1:
update to 10.5.0:
update to 10.4.1:
includes 10.4.0:
update to 10.3.0:
update to 10.2.1:
includes 10.2.0:
update to 10.1.0:
update to 10.0.0:
update to 9.15.3:
update to 9.15.2:
update to version 9.15.1:
update to version 9.15.0:
update to version 9.14.4:
includes 9.14.3:
update to version 9.14.2: pnpm publish --json should work #8788
includes 9.14.1:
includes 9.14.0:
update to version 9.13.2:
update to version 9.13.1:
update to version 9.13.0:
update to version 9.12.3:
includes 9.12.2: