Zoltan Kochan
c9b8632ea6
Registries do not all lay out tarball URLs the way the npm registry does. JFrog Artifactory repeats the scope in a scoped package's tarball filename (`@acme/widget/-/@acme/widget-1.0.0.tgz`) where npm strips it. pnpm cannot rebuild such a URL, so it writes it out for every scoped package instead of omitting it, and the lockfile carries a host-specific URL per dependency. pnpm had no place to record such a fact, because it had no place to describe a registry at all — only three ways to name one. `registries` mapped a scope to a URL, `namedRegistries` mapped a bare-specifier prefix to a URL, and neither could carry anything else. `registries` now declares a registry once, keyed by its URL, with every fact about it in the entry: a `serverType`, the `scopes` routed to it, and the `prefix` it answers to. `serverType` has three states: undeclared strict; only the exact canonical URL is reconstructible npm also serves the percent-encoded scoped path artifactory repeats the scope in the tarball filename registry.npmjs.org resolves to `npm` as a built-in, so its behavior is unchanged and the old hostname check becomes that one default rather than a special case in the predicate. `npm` cannot be the default: asserting npmjs-compatibility is a claim only the operator can make. The URL is the key because every fact in an entry is a fact about that server. Keying the layout by scope would bind it to whoever the scope currently points at, so two developers whose scope resolves differently would write lockfiles that disagree about which URLs may be omitted. `scopes` and `prefix` are routes to the registry and are inverted at config-read time into the two lookups the rest of pnpm already queries, leaving the resolver, installer, and lockfile layers untouched and the precedence chain (builtin < .npmrc < yaml < `_auth` < CLI) unchanged. The layout is declared, never inferred. Sniffing the registry URL cannot work: a virtual repository serves both layouts at once, depending on whether each package was synced from upstream or published locally, so no registry-level signal — route, response header, or probe — decides it. Declaring it also keeps a wrong guess a fixable misconfiguration instead of a silent breakage. `serverType` feeds a single URL builder that both sides of the lockfile use: the writer omits a tarball URL only when the builder reproduces it, and the reader rebuilds it with the same call. They therefore agree by construction, so pnpm never has to assume a registry serves some second URL as well. The setting lives in pnpm-workspace.yaml rather than .npmrc because the lockfile depends on it: one developer omitting URLs that another reconstructs differently would break a frozen install. A `serverType` in the global config.yaml is ignored for the same reason, while the routes declared alongside it are kept. Credentials are rejected there — the file is committed — and still belong in .npmrc. The registry URL is the map key, so the request-destination env gate applies to keys as well as values. Credentials and unknown fields are refused after parsing, since a parse error renders the offending source line verbatim. A map whose values are all strings is the older `<scope>: <url>` shape and is still read as one. Mixing the two shapes in one map is refused, and so is a URL-keyed entry written as a string. `namedRegistries` is deprecated in favor of `prefix` and is read only for prefixes `registries` does not declare; a prefix stays singular because it is the registry's identity in a lockfile dep path. An entry that routes nothing to itself and matches no configured registry is reported as a warning rather than silently ignored; it is a warning and not an error because a shared config dependency can legitimately describe registries a given project does not use. Config dependencies and pnpr-server-mode resolution pass no server type; in both, the writer and the reader share that default, so they stay consistent. Closes pnpm/get-npm-tarball-url#16. Supersedes pnpm/pnpm#13920.
简体中文 | 日本語 | 한국어 | 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.