Comparing changes

* chore: update dependencies, Node.js, pnpm, and GitHub Actions * chore: generate the embedded CAS loader bundle on install The CAS loader that `deps-restorer` embeds with include_str! was a minified esbuild bundle committed to the repo. Every enhanced-resolve or esbuild bump rewrote most of it, and a stale copy failed CI with a byte-by-byte assertion diff. `@pnpm/esm-loader` now generates it from a `prepare` script, so every `pnpm install` that includes the package writes it before cargo builds. Cargo already depends on that install for `.pnpm/crates`. The package gets its own esbuild devDependency instead of borrowing pnpm11/pnpm's. The filtered installs that feed cargo (install-crates and the wasm release job) now also select `@pnpm/esm-loader`. Also ignore GHSA-hp3w-g68c-fv3c. sprintf-js has no patched release, and it is reached only through argparse 1 formatting its own help text. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * chore: write the CAS loader bundle atomically and generate it for wasm CI An interrupted `prepare` could leave a truncated bundle that a later up-to-date install never rewrites. Write to a temporary file and rename. The pnpm-wasm workflow builds the CLI after a filtered install, so it now selects `@pnpm/esm-loader` too. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

…les files (#16644) Two defects made `nodeLinker.type: loaded` unusable in a real workspace. Runtime dependencies (`node@runtime:`, from `devEngines.runtime`) were loaded from CAS like any other package, so their bins got the loader's JavaScript `runMain` shim. That shim starts with `#!/usr/bin/env node` and sits first on the scripts' PATH as `.pnpm/.bin/node`, so `env node` resolved back to the shim and re-executed it until execve failed with E2BIG. A runtime's executables are native binaries the loader cannot run, so runtime snapshots now join patched packages in the set the loaded linker always materializes in the global virtual store. The loader validates every file of every package when it starts and rejected the manifest if a file path had a `node_modules` segment. One package shipping such a file, such as the test fixtures of resolve@1.22.12, made every Node.js process fail with ERR_PNPM_LOADER_MANIFEST. Bundled dependencies are not supported by the loader, so it now skips those files when it builds the virtual filesystem. The manifest still lists them, because `pnpm store prune` keeps only the CAS blobs a loader manifest references.

…nstall (#16639) The catalogPrune pass on install runs before the lockfile freshness check and decides what is unused from the projects on disk. In a filtered frozen install with some workspace projects missing, it removed catalog entries the lockfile still records for those projects, and the frozen check then failed with ERR_PNPM_LOCKFILE_CONFIG_MISMATCH. A frozen install cannot rewrite the lockfile, so it now passes the lockfile's catalogs to the workspace manifest writer as entries to keep. The writer adds a catalog reference for each of them before the prune. Entries the lockfile does not record are still pruned. Fixes #16638

) The loader kept files under a package's own `node_modules` out of its virtual filesystem, so a stored package that requires one of its bundled dependencies (npm, cnpm) failed with ERR_PNPM_LOADER_UNDECLARED_DEPENDENCY. Those files are now indexed like any other. A bare specifier from inside a stored package resolves to a `node_modules/<name>` directory within that package when one between the issuer and the package root provides it, before the declared dependencies, as Node's lookup would. Lookups still never leave the package root. Packages without such files skip the walk.

…quest warning (#16647) The "Request took" warning started its timer before the metadata request acquired its concurrency permits, so time spent queued behind other requests in pnpm's own pool was reported as the registry being slow. A large install that resolves thousands of packages while downloading tarballs printed hundreds of these warnings against a healthy registry. v11 resolves inside a requestsQueue slot and starts the timer right before the fetch, so its warning never counted that wait. The ThrottledClientGuard now records when it got its last permit, and both metadata paths start the timer there. A retried request is timed from the permit of the attempt whose body is read.

The loaded linker wrote `.pnpm-store.json` and `.pnpm-store-loader.mjs` to the project root and moved `modulesDir` to a root `.pnpm` directory, so every project had to add three entries to `.gitignore`. Loaded mode now keeps the default `modulesDir`. Bin shims go to `node_modules/.bin`, installation state to `node_modules`, and the store manifest, loader, and CAS bin state to `node_modules/.pnpm` as `.store-manifest.json`, `.store-loader.mjs`, and `.cas-bin-names.json`. `node_modules` holds only dot entries, never packages. Loaded installs now register `node_modules/.pnpm` in the store's project registry instead of the project root. Prune reads the manifest from the registered directory, so a custom `modulesDir` still protects the blobs the project references. The standalone `register.mjs` defaults to the new manifest path.

…on projects (#16650) The ecosystem inventory walked the whole workspace tree, so a git worktree nested inside it (for example an agent worktree under `.claude/worktrees`) had its Cargo workspace discovered, its crates fetched and linked, and its whole tree scanned on every install of the outer workspace. The walk now prunes a descendant directory that holds `pnpm-workspace.yaml` or a `.git` directory: that is a separate workspace or clone, which installs on its own. A `.git` file does not prune, because git submodules use one and a submodule is content of the outer checkout. The check reuses the entries the walk already reads, so it costs no extra syscalls.

…ent lockfile records (#16649) A project's current lockfile only vouches for slots that project alone writes. A global virtual store slot is shared, so another project's interrupted install may have re-created it without its child links or package files after the record was written. The warm-slot probe now checks the completion marker and every child link of a GVS slot even when the current lockfile records it unchanged. The repeat-install fast path and the frozen up-to-date short-circuit still run before the probe, so an install in an unchanged project does not reach it. Related to #16642.

…file (#6784) `pnpm install --fix-lockfile` cleared `deprecated` and `hasBin` from every package entry before re-resolving, and the resolver did not regenerate them: v11 reuses locked entries without reading the manifest (so `hasBin` became false and `deprecated` vanished), and v12 lost any deprecation the registry metadata does not carry because the seed lockfile it carries deprecations from had been cleared. Keep both fields in the repair seed in v11 (forgetRegeneratedLockfileFields) and v12 (Lockfile::prepare_for_fix). Entries that fail to decode are still narrowed to their resolution by the v12 repair loader. Closes #6600 --------- Co-authored-by: Zoltan Kochan <z@kochan.io> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

#16648) pnpm 11 releases older than 11.28.4 linked the bins of a pnpm 12 store slot without force. The first link, made while the wrapper's bin was still the `#!/usr/bin/env node` placeholder, wrote a shim that runs `node`. The second link, after the native binary replaced the placeholder, kept that shim because its target path had not changed. installPnpmToStore reused any slot whose bin directory existed, so the broken shim survived an upgrade to a fixed pnpm 11. After linking a slot's bins, installPnpmToStore now writes a `.pnpm-bins-linked` marker holding the running pnpm version. On reuse, a missing or different marker makes it relink with force, under the slot's lock and after rechecking the marker. pnpm v12 already does this for its engine store (`linked_bins.rs`), so only v11 needs the fix. Closes #16646

…removed (#16645) The registry fixture publisher is built around publishers racing: each process claims an unusable tree with a rename, re-checks the completion marker, and removes what it claimed. Every removal in that path, though, used `expect`, so a tree that is already gone was fatal rather than the outcome asked for. Windows surfaces it. A test run on the CLI crate died in `discard_unusable_storage` with NotFound on the path the same function had just renamed into place, and nextest cancelled the seven tests still running with it. The claim name carries the process id and a counter, so no other publisher can target it by name; the tree can still go out from under the removal, and the panic took a whole run with it. `remove_tree` accepts `NotFound` and keeps every other error fatal. The four publisher removals go through it, and the two `exists()` checks that guarded a removal are gone with it: they only narrowed the window they were meant to close. The final publish in `publish_storage` still fails loudly. It needs a tree without a marker to appear between the discard and the rename, and a publisher writes the marker before it publishes, so reaching it takes a crashed publisher rather than a lost race.

The loader indexed every file of every stored package at startup: validating each name and hash, joining its virtual path, and recording every parent directory. Each Node.js process paid that cost before running any code, about 50 ms for 13,000 files and 320 ms for 110,000. Packages are now indexed the first time a path inside them is resolved, statted, or read. Package roots, dependency maps, and the manifest parse stay eager, so owner lookups and dependency checks behave as before. A malformed file entry is now reported when its package is first used rather than at startup. Indexing is all-or-nothing and the error is cached, so a failure inside enhanced-resolve, which turns filesystem errors into "Can't resolve", cannot leave a partial index behind. The resolver indexes a dependency before handing it to enhanced-resolve so that the manifest error itself reaches the user.

…ge (#16658) Lockfiles written before #15503 record an optional peer that the package also depends on as the peer's provider. When that provider is an npm alias of another package, the snapshot keeps it, for example `ajv-formats@3.0.1(@redocly/ajv@8.18.3)` with `optionalDependencies: { ajv: '@redocly/ajv@8.18.3' }`. Since #15503 the name is resolved as a regular dependency again, from its plain range (`ajv: ^8.0.0`). The check that decides whether the locked ref still satisfies that range compared only the version, so the alias was accepted. The resolver then either kept the other package under the alias or, when it looks the locked version up in the registry as the default minimumReleaseAge makes it do, asked for `ajv@8.18.3` and failed with ERR_PNPM_NO_MATCHING_VERSION. Overrides with a version range in the selector reach this path because they skip the fast override rewrite. A plain range now requires the locked package to have the alias's own name, in both the TypeScript resolver (getRangeOfLockedPackage) and the Rust resolver (prior_child_key). Non-range specifiers such as git and tarball URLs keep their existing handling. Closes #16654

`@pnpm/napi`'s `rebuild()` runs as a frozen install, so it ran the frozen install's settings-drift check (pnpmfileChecksum, overrides, packageExtensionsChecksum, ...). A rebuild resolves nothing, so of those settings only the patches change what it builds. The check broke `rebuild()` for every lockfile that records a pnpmfileChecksum. `rebuild()` takes no readPackageHook, and the readPackageHookChecksum option is only recorded for a hook passed to the same call, so the current checksum was always None and never matched. RebuildOptions gets check_lockfile_patches_only. When it is set, the frozen dispatch checks only the lockfile's patchedDependencies against the configured patch hashes, plus the lockfile's own patch_hash consistency, in place of the settings-drift check. That is what pnpm v11's rebuild compares. The manifest specifier gate still runs: a v12 rebuild materializes the wanted lockfile, so it must not fetch and build a dependency the manifests no longer declare (ignorePackageManifest turns it off, as before). That gate rewrites direct-dependency specifiers with the overrides, so a patches-only check applies the overrides the lockfile records rather than the current ones. The napi rebuild sets the option; the CLI's `pnpm rebuild` keeps the full gate.

* chore(release): pacquet 12.10.1 * docs(release): curate pacquet 12.10.1 release notes Add a lead paragraph, group the loaded-linker entries with the one users must act on first, and use one wording for the setting across them. Drop the napi note's claim that `pnpm rebuild` checks only the patches: the v12 CLI keeps the full frozen-lockfile check. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

Navigation Menu

Repository navigation

Comparing changes

Open a pull request

Commits on Oct 6, 2026

This comparison is taking too long to generate.

Uh oh!