Zoltan Kochan
c42f69ffaf
* ci(pnpm-registry): add manual release workflow that publishes to npm Mirror pacquet's release pipeline for the pnpm-registry crate: - New `Release pnpm-registry` GitHub workflow (manual `workflow_dispatch` with a version input) builds the `pnpm-registry` binary for six `<os>-<cpu>` matrix legs via `cross`, attests provenance, and uploads artifacts. - The publish job patches `registry/npm/pnpm-registry/package.json`'s `version` field with the input, downloads the artifacts, runs `generate-packages.mjs` to produce per-platform packages, then publishes everything via `pnpm publish --provenance` using OIDC. - The wrapper package is `pnpm-registry`; the per-platform binary packages are scoped `@pnpm/registry.<os>-<cpu>` and resolved by a Node shim under `bin/pnpm-registry`. The CLI's `--version` output comes from `CARGO_PKG_VERSION` via clap's derive `version` attribute, so the build leg patches the crate's `Cargo.toml` `version` field rather than a hardcoded clap string. --- Written by an agent (Claude Code, claude-opus-4-7). * ci(pnpr): rename package to @pnpm/pnpr with @pnpm/pnpr.<os>-<cpu> binaries Shorter, scoped name that reads naturally on npm: `@pnpm/pnpr` for the wrapper, `@pnpm/pnpr.<os>-<cpu>` for the six per-platform binary packages (mirroring `@pacquet/<os>-<cpu>` under a different scope). - Move `registry/npm/pnpm-registry/` to `registry/npm/pnpr/` and rename the JS shim and `bin` entry to `pnpr`. - Update `generate-packages.mjs` so `BIN_NAME = pnpr` (used for both the binary file inside each platform package and the autogenerated package dir) and the scope/prefix produce `@pnpm/pnpr.<os>-<cpu>`. - Rename the workflow file to `pnpr-release-to-npm.yml` and rename the built `pnpm-registry` binary to `pnpr-<code-target>` at archive time, so `generate-packages.mjs` finds it at `REPO_ROOT/pnpr-<plat>-<arch>`. - The Rust crate name stays `pnpm-registry` (still what `cross build -p` targets); only the npm-publishing layer is renamed. --- Written by an agent (Claude Code, claude-opus-4-7). * fix(pnpr): propagate signal exits through the Node shim `spawnSync` returns `result.status === null` when the child terminates via a signal. Assigning that to `process.exitCode` makes the parent exit 0 and masks the signal — bad for a long-running server where the operator is most likely to kill it with SIGINT/SIGTERM. Re-raise the signal so the parent terminates the same way, falling back to a non-zero exit code if for some reason we can't. --- Written by an agent (Claude Code, claude-opus-4-7).
简体中文 | 日本語 | 한국어 | 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:
