pnpm

library1.0.14jsnpmunverified

pnpm (performant npm) is a fast, disk space efficient package manager for JavaScript and TypeScript projects. It differentiates itself by using a content-addressable filesystem with hard links and symlinks to store all files from all module directories on a disk, saving significant disk space and speeding up installations, especially in monorepos. The current stable version is 10.33.0, with active development ongoing for the upcoming version 11.0.0, which introduces several breaking changes and new features.

devops

npm install pnpm

github ↗package ↗homepage ↗

INSTALL

IMPORT

SIG · PNPM

pnpm

devopsjavascriptv1.0.14

Install

—

Import

—

Disk

—

Pass rate

0/ 6

Env Coverage0 / 6

glibc

18–22

musl

18–22

Install & Compatibility

Where this runs

tested against v? · npm install

Install × environment matrix

Each cell = how many times install + import succeeded across repeated harness runs. Partial = flaky.
glibc = Debian/Ubuntu slim · musl = Alpine Linux

musl

node 18–226 runs

build_error

glibc

node 18–226 runs

build_error

Code

Verified usage

Verified import paths — ran on the pinned version, not inferred.

pnpm CLI

✓ npx pnpm@latest install

✗ import { install } from 'pnpm';

The 'pnpm' package is primarily a command-line interface (CLI) tool and does not expose JavaScript symbols for direct import into applications. Programmatic interaction is typically done by executing CLI commands via child processes. The example shows using `npx` to ensure the correct version of pnpm is used.

pnpm configuration types

✓ import type { Config } from '@pnpm/types';

✗ import { Config } from 'pnpm/config';

While the main 'pnpm' package isn't a library, its ecosystem includes separate packages like '@pnpm/types' which provide TypeScript definitions for configuration or internal structures, useful for tooling. This is an example of importing types from a related package within the pnpm ecosystem for advanced programmatic use cases.

runPnpm

✓ import { runPnpm } from '@pnpm/exec';

✗ import pnpm from 'pnpm/cli';

For integrating pnpm functionality into JavaScript/TypeScript applications, one might use related packages like '@pnpm/exec' (if available and stable for public use) to programmatically execute pnpm commands. Direct imports from the 'pnpm' package itself are not supported for its core CLI functionality.

This TypeScript quickstart demonstrates how to programmatically execute `pnpm install` for a project using the `execa` library, which is a common way to interact with CLI tools from Node.js applications. It logs the output and handles potential errors during the installation process.

import { execa } from 'execa'; async function runPnpmInstall(projectPath: string) { try { console.log(`Running pnpm install in ${projectPath}...`); const { stdout, stderr } = await execa('pnpm', ['install'], { cwd: projectPath }); console.log('pnpm install stdout:', stdout); if (stderr) { console.warn('pnpm install stderr:', stderr); } console.log('pnpm install completed successfully.'); } catch (error: any) { console.error(`Error running pnpm install in ${projectPath}:`, error.message); process.exit(1); } } // Example usage: Ensure you have a 'package.json' in './my-project' // or replace './my-project' with an actual path. runPnpmInstall('./');

pnpm --version

Debug

Known issues

breakingpnpm v11 requires Node.js 22+; support for Node 18, 19, 20, and 21 has been dropped. Additionally, pnpm itself is now pure ESM, and the standalone executable requires glibc 2.27.

fix

Upgrade your Node.js environment to version 22 or higher. For standalone executables on Linux, ensure glibc 2.27 or newer is available. If using pnpm as a Node.js module, ensure your project environment supports pure ESM.

affects: >=11.0.0-rc.0

breakingThe `managePackageManagerVersions`, `packageManagerStrict`, and `packageManagerStrictVersion` settings have been removed in favor of the more comprehensive `pmOnFail` setting, which directly controls the `onFail` behavior for both `packageManager` and `devEngines.packageManager` fields. The `COREPACK_ENABLE_STRICT` environment variable is no longer honored.

fix

Migrate your configuration to use the `pmOnFail` setting in `pnpm-workspace.yaml` or through the CLI. Remove any references to the deprecated settings and environment variable.

affects: >=11.0.0-rc.2

breakingThe `pnpm audit` command now uses npm's `/-/npm/v1/security/advisories/bulk` endpoint, which does not return CVE identifiers. CVE-based filtering (`auditConfig.ignoreCves`) has been replaced with GitHub advisory ID (GHSA) filtering (`auditConfig.ignoreGhsas`).

fix

Update your `auditConfig` in `pnpm-workspace.yaml` (or global config) to use `auditConfig.ignoreGhsas` instead of `auditConfig.ignoreCves`. Replace any CVE-YYYY-NNNNN entries with their corresponding GHSA-xxxx-xxxx-xxxx values, which can be found in the 'More info' column of `pnpm audit` output.

affects: >=11.0.0-rc.1

breakingThe `allowBuilds` setting replaces all previous build-dependency settings, including `onlyBuiltDependencies`, `onlyBuiltDependenciesFile`, `neverBuiltDependencies`, `ignoredBuiltDependencies`, and `ignoreDepScripts`.

fix

Refactor your build-related configurations to use the `allowBuilds` map in `pnpm-workspace.yaml`. This setting allows explicit control over script execution for specific packages.

affects: >=11.0.0-rc.0

gotchaSupply-chain protection features, including `minimumReleaseAge` (defaults to 1 day) and `blockExoticSubdeps` (defaults to `true`), are now enabled by default. This prevents newly published packages from being resolved for 24 hours and blocks exotic subdependencies.

fix

If your workflow requires immediate resolution of new packages or allows exotic subdependencies, configure `minimumReleaseAge: 0` and/or `blockExoticSubdeps: false` in your `pnpm-workspace.yaml` or global config.

affects: >=11.0.0-rc.0

gotchaCLI output for script execution is cleaner, printing `$` command instead of detailed `> pkg@version stage path\n> command`. Peer dependency issues are no longer rendered as a full tree during install; instead, users are suggested to run `pnpm peers check`.

fix

Adjust any automated scripts or CI/CD pipelines that parse pnpm's CLI output for script execution or peer dependency issues. Use `pnpm peers check` for detailed peer dependency reports.

affects: >=11.0.0-beta.8

breakingRuntime dependencies are now always linked from the global virtual store. While this optimizes storage and installation speed, it might affect tools that expect a specific `node_modules` structure, especially with ESM modules due to Node.js not respecting `NODE_PATH` for ESM imports.

fix

Review existing tooling and scripts that rely on the `node_modules` structure. For ESM resolution issues, consider using `packageExtensions` or `@pnpm/plugin-esm-node-path` as workarounds.

affects: >=11.0.0-beta.3

Errors

Common errors & fixes

ERR_PNPM_UNSUPPORTED_ENGINE Unsupported environment (bad pnpm and/or Node.js version) Your Node version is incompatible...

The installed Node.js version does not meet the requirements specified in the project's `engines.node` field or pnpm's own requirements.

fix

Upgrade your Node.js version to meet the required specification. Use `pnpm env use <version>` or a Node.js version manager (e.g., `nvm`, `volta`) to switch to a compatible version.

Cannot perform a frozen installation because the version of the lockfile is incompatible with this version of pnpm

The `pnpm-lock.yaml` file was generated with a different, incompatible version of pnpm than the one currently being used for installation, often seen in CI/CD environments with `--frozen-lockfile` enabled.

fix

Update your pnpm version to match the one that generated the lockfile, or run `pnpm install` locally with the current pnpm version to migrate the lockfile, then commit the changes. Alternatively, use `pnpm install --no-frozen-lockfile` (though this is not recommended for CI).

ERROR: 'auditConfig.ignoreCves' is no longer recognized. Please use 'auditConfig.ignoreGhsas' instead.

After pnpm v11.0.0-rc.1, `pnpm audit` switched to GitHub advisory IDs (GHSAs) instead of CVEs for ignoring vulnerabilities, rendering the old configuration key invalid.

fix

Rename `auditConfig.ignoreCves` to `auditConfig.ignoreGhsas` in your `pnpm-workspace.yaml` or global config file, and update any CVE-XXXX-YYYYY entries to their corresponding GHSA-XXXX-XXXX-XXXX values.

ERR_PNPM_PEER_DEP_ISSUES pnpm install will fail if the project has unresolved peer dependencies or the peer dependencies are not matching the wanted ranges.

Your project has peer dependency requirements that are not met by the currently installed dependencies.

fix

Install the missing peer dependencies, or explicitly define `peerDependencyRules.ignoreMissing` and/or `peerDependencyRules.allowedVersions` in `pnpm-workspace.yaml` to tolerate specific issues. Consider running `pnpm peers check` for detailed information.

Cannot find module '@some/package'

This error can occur during a build process, especially in monorepos or with strict dependency linking, if a package attempts to import a module that is not explicitly declared in its `package.json` dependencies.

fix

Ensure that all direct and transitive dependencies are explicitly listed in the `dependencies` or `devDependencies` of the `package.json` for the package requiring them. If a package is being used in a way that bypasses pnpm's strict linking (e.g., hoisted modules for ESM), review the `nodeLinker` and `shamefullyHoist` settings, or use `packageExtensions`.

Upgrade

Version history

1.0.14latest on npm

Audit

Dependencies

No dependency data recorded yet.

Agent activity

4 hits · last 30 days

node

Resources

githubhttps://github.com/pnpm/pnpm ↗

packagehttps://www.npmjs.com/package/pnpm ↗

homepagehttps://pnpm.io ↗