mirror of
https://github.com/pnpm/pnpm.git
synced 2026-07-14 17:52:44 -04:00
dcabb78620
Contract: `pnpm up <pkg>` produces the same lockfile a fresh install of the same manifests would (equivalently: delete the target's lockfile entries and run `pnpm install`). pnpm (TypeScript): - Thread a per-wanted-dependency `updateRequested` flag (true only for packages matching the user's update target) from the deps-resolver through requestPackage to the npm picker. - At the picker, `stripLockfileVersionPins` subtracts EXISTING_VERSION_SELECTOR_WEIGHT from the target's version-type selectors (the lockfile seed's contribution, which is added onto manifest entries pinning the same version) and drops a selector only when nothing remains. Manifest pins, down-chain propagated versions, and range/tag selectors (audit-fix penalties) keep applying. - Always seed `preferredVersions` from the lockfile, also during update mutations (pnpm/pnpm#10662); caller-supplied preferred versions (audit-fix penalties) merge over the seed per package name on a null-prototype target. - New held-back-update warning at both npm picker entry points: when `updateRequested` and a kept preferred selector steers the pick below what the non-pin selectors alone would choose, warn once per (name, picked, preferred) recommending a pnpm.overrides entry. - `pnpm update <dep>@<version>` for a transitive-only <dep> warns that the version part is ignored and recommends an override (pnpm/pnpm#12744). pacquet (same behavior): - The picker strips nothing: UpdateSeedPolicy::DropOnly already withholds the target's lockfile pins from the preferred-versions seed. `update_requested` (derived per wanted dependency via `is_update_target`, matching npm-alias and jsr real names) gates the held-back-update warning emitted by `warn_once_on_held_back_update`, with the same message as the TypeScript side. - `pacquet update <pkg>@<version>` on a transitive-only package warns that the version part is ignored, mirroring the TypeScript wording. Coverage: resolver-level tests in both stacks assert that the lockfile-pin strip lets the target move, that manifest pins, propagated versions, combined manifest+lockfile entries (manifest weight preserved), and audit penalties keep steering, and e2e tests assert the same-chain and importer-pin topologies dedupe under update exactly as a fresh install does (fresh-install behavior verified empirically against the registry mock). The transitive-version update resolves to highest-in-range with the override recommendation, and crafted package names (`__proto__@1.0.0`) cannot pollute Object.prototype. Closes pnpm/pnpm#10662. Closes pnpm/pnpm#12744. Co-authored-by: Minha Kang <118591632+m2na7@users.noreply.github.com> --------- Co-authored-by: Zoltan Kochan <z@kochan.io> Co-authored-by: Minha Kang <118591632+m2na7@users.noreply.github.com>
简体中文 | 日本語 | 한국어 | 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.