mirror of
https://github.com/pnpm/pnpm.git
synced 2026-07-19 20:22:21 -04:00
352c079c44
Error codes are a public contract — users match on them in CI and scripts, and pnpm documents them at https://pnpm.io/errors. 284 of pacquet's `#[diagnostic(code(...))]` sites reported something else: $ pnpm root -g Error: pacquet_cli::root_global_unsupported `pacquet` is an in-repo crate name that means nothing to a user of the `pnpm` binary. A second group reported unprefixed codes (`GIT_CHECKOUT_FAILED`), which are the *short* names pnpm passes to `PnpmError`; its constructor prepends `ERR_PNPM_` before the code is ever observed, so pacquet was emitting a code pnpm never emits. Rename all 259 offending codes across 284 sites under two rules: 1. Where pnpm defines a code for the same error, use pnpm's exact code. `pacquet_package_manager::outdated_lockfile` becomes `ERR_PNPM_OUTDATED_LOCKFILE` — which its own doc comment already claimed it was — and `GIT_CHECKOUT_FAILED` becomes `ERR_PNPM_GIT_CHECKOUT_FAILED`. 2. Otherwise derive from the full path minus the crate prefix, so `pacquet::patch_state_read` becomes `ERR_PNPM_PATCH_STATE_READ`. The namespace is retained rather than the leaf alone: six distinct `create_dir` errors would otherwise collapse onto one code. Three merge onto codes pacquet already used elsewhere for the same condition, which is the intent, not a clash. pnpm has a single `ERR_PNPM_TRUST_DOWNGRADE` and matches on it by name in `deps-resolver`, so pacquet's resolver-side and lockfile-side trust downgrades now share it. Two errors were mislabelled and are corrected rather than renamed: - `frozen_lockfile_with_outdated_lockfile` is not pnpm's outdated-lockfile error. The variant is `FrozenLockfileWithUpdateChecksums` and the message is about combining --frozen-lockfile with --update-checksums. It takes `ERR_PNPM_CONFIG_CONFLICT_FROZEN_LOCKFILE_WITH_UPDATE_CHECKSUMS`, following the existing ERR_PNPM_CONFIG_CONFLICT_* convention, and its doc comment no longer claims to be the error it isn't. - Three package-manifest errors have pnpm equivalents under a different name, which rule 1 cannot see because it matches on the name: "package.json file already exists" is pnpm's `PACKAGE_JSON_EXISTS` (thrown by `pnpm init`), "No package.json was found" is `NO_IMPORTER_MANIFEST_FOUND`, and "Missing script" is `NO_SCRIPT`. All 610 diagnostic codes are now ERR_PNPM_*.
简体中文 | 日本語 | 한국어 | Italiano | Português Brasileiro
Fast, disk space efficient package manager:
- Fast. Up to 2x faster than the alternatives (see benchmark).
- Efficient. Files inside
node_modulesare linked from a single content-addressable storage. - Great for monorepos.
- Strict. A package can access only dependencies that are specified in its
package.json. - Deterministic. Has a lockfile called
pnpm-lock.yaml. - Works as a Node.js version manager. See pnpm runtime.
- Works everywhere. Supports Windows, Linux, and macOS.
- Battle-tested. Used in production by teams of all sizes since 2016.
- Experimental Rust port. Includes pacquet, an experimental port of the CLI written in Rust.
- See the full feature comparison with npm and Yarn.
To quote the Rush team:
Microsoft uses pnpm in Rush repos with hundreds of projects and hundreds of PRs per day, and we’ve found it to be very fast and reliable.
Platinum Sponsors
|
|
Gold Sponsors
|
|
|
|
|
|
|
|
Silver Sponsors
|
|
|
|
|
|
|
|
|
| ⏱️ Time.now |
Support this project by becoming a sponsor.
Background
pnpm uses a content-addressable filesystem to store all files from all module directories on a disk. When using npm, if you have 100 projects using lodash, you will have 100 copies of lodash on disk. With pnpm, lodash will be stored in a content-addressable storage, so:
- If you depend on different versions of lodash, only the files that differ are added to the store.
If lodash has 100 files, and a new version has a change only in one of those files,
pnpm updatewill only add 1 new file to the storage. - All the files are saved in a single place on the disk. When packages are installed, their files are linked from that single place consuming no additional disk space. Linking is performed using either hard-links or reflinks (copy-on-write).
As a result, you save gigabytes of space on your disk and you have a lot faster installations!
If you'd like more details about the unique node_modules structure that pnpm creates and
why it works fine with the Node.js ecosystem, read this small article: Flat node_modules is not the only way.
💖 Like this project? Let people know with a tweet
Getting Started
Benchmark
pnpm is up to 2x faster than npm and Yarn classic. See all benchmarks here.
Benchmarks on an app with lots of dependencies:
License
MIT, except the pnpr/ directory, which is source-available under the PolyForm Shield License 1.0.0.