mirror of
https://github.com/pnpm/pnpm.git
synced 2026-05-16 21:00:37 -04:00
b187a38bc6
* chore(release): wrap changeset version with cross-branch consumed-id ledger When a fix is cherry-picked from main to a release branch (or vice versa), the changeset file ends up on both branches. The release branch's release consumes and deletes its copy, but the cherry-picked copy on main survives the merge back and would be re-applied on the next main release. Introduce a small wrapper around `changeset version` that maintains a per-branch ledger at .changeset/.released/<branch>.txt. Each entry is a consumed changeset id; the file is written only by the branch it is named after, so the records merge across branches without conflicts. Before running `changeset version` the wrapper reads the union of every ledger file, hides matching .changeset/<id>.md files (rename to .md.released), then runs `changeset version` against the remaining set. Newly consumed ids are appended to the current branch's ledger; hidden files are removed afterward (their consumption is already on record elsewhere). On failure the hidden files are restored to keep the working tree clean. * docs: move release-ledger explanation out of AGENTS.md AGENTS.md is for instructions to AI agents working on the codebase, but the cross-branch ledger is release machinery that the maintainer running `pnpm bump` interacts with — agents authoring changesets do not need to know about it. Move the explanation to where someone runs into it: - .changeset/.released/README.md — discovered by anyone exploring the directory. - A short doc-comment header at the top of __utils__/scripts/src/bump.ts pointing readers there. * fix(scripts): harden bump wrapper edge cases from PR review - Use url.pathToFileURL(realpathSync(...)) to compare against import.meta.url so the direct-invocation guard works on Windows paths and through symlinks (Copilot review). - hideReleased() now iterates the changeset directory and filters by the released set instead of iterating the (potentially long) ledger and probing existsSync per entry (Copilot review). - hideReleased() restores already-renamed files if a later rename throws, so a partial failure leaves the .changeset directory in its original state (CodeRabbit review). - Move deleteHidden() into a finally so the .md.released files are cleaned up even if appendReleased() throws after a successful changeset version run (CodeRabbit review). - Add a unit test that forces hideReleased() to fail mid-loop and asserts the rollback.
简体中文 | 日本語 | 한국어 | 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.
- 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:
