chore(release): pacquet 12.0.0-rc.0 (#13667)

Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
2026-10-12 05:04:40 -04:00 · 2026-08-05 21:42:03 +02:00
1 parent 6e39ea3def
commit b286ddbfbf
@@ -1,10 +0,0 @@
-## 1100.0.25
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/assert-store@1100.0.25
-  - @pnpm/constants@1101.0.0
-  - @pnpm/installing.modules-yaml@1100.0.15
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/types@1101.9.0
@@ -1,7 +0,0 @@
-## 1100.0.25
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/store.cafs@1100.1.18
-  - @pnpm/store.index@1100.2.3
@@ -1,11 +0,0 @@
-## 1100.3.1
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/cli.utils@1101.0.22
-  - @pnpm/config.reader@1101.16.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/network.fetch@1100.1.11
-  - @pnpm/network.web-auth@1101.4.1
-  - @pnpm/registry-access.client@1100.1.13
@@ -1,11 +0,0 @@
-## 1100.0.25
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/bins.resolver@1100.0.14
-  - @pnpm/error@1100.1.1
-  - @pnpm/pkg-manifest.reader@1100.0.15
-  - @pnpm/pkg-manifest.utils@1100.3.1
-  - @pnpm/types@1101.9.0
-  - @pnpm/workspace.project-manifest-reader@1100.0.23
@@ -1,9 +0,0 @@
-## 1100.0.19
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/bins.resolver@1100.0.14
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/pkg-manifest.reader@1100.0.15
-  - @pnpm/types@1101.9.0
@@ -1,6 +0,0 @@
-## 1100.0.14
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/types@1101.9.0
@@ -1,30 +0,0 @@
-## 1102.0.15
-
-### Patch Changes
-
- Security: `pnpm rebuild` now refuses a lockfile whose `packages` key carries a path traversal in the package name (e.g. `../../../escaped@1.0.0`), instead of running that package's lifecycle scripts and linking its bins in a directory outside the virtual store. Such a name is rejected with `ERR_PNPM_INVALID_DEPENDENCY_NAME`.
-
- Updated dependencies:
-  - @pnpm/bins.linker@1100.0.25
-  - @pnpm/building.pkg-requires-build@1100.0.14
-  - @pnpm/building.policy@1100.0.18
-  - @pnpm/config.normalize-registries@1100.1.0
-  - @pnpm/config.reader@1101.16.0
-  - @pnpm/constants@1101.0.0
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/deps.graph-hasher@1100.2.15
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/exec.lifecycle@1100.1.11
-  - @pnpm/fs.symlink-dependency@1100.0.17
-  - @pnpm/installing.context@1100.1.0
-  - @pnpm/installing.modules-yaml@1100.0.15
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/lockfile.utils@1101.0.0
-  - @pnpm/lockfile.walker@1100.0.19
-  - @pnpm/pkg-manifest.reader@1100.0.15
-  - @pnpm/store.cafs@1100.1.18
-  - @pnpm/store.connection-manager@1100.3.15
-  - @pnpm/store.controller-types@1101.1.0
-  - @pnpm/store.index@1100.2.3
-  - @pnpm/types@1101.9.0
@@ -1,17 +0,0 @@
-## 1100.1.20
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/building.after-install@1102.0.15
-  - @pnpm/building.policy@1100.0.18
-  - @pnpm/cli.utils@1101.0.22
-  - @pnpm/config.reader@1101.16.0
-  - @pnpm/config.writer@1100.0.21
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/installing.commands@1100.13.0
-  - @pnpm/installing.modules-yaml@1100.0.15
-  - @pnpm/store.connection-manager@1100.3.15
-  - @pnpm/types@1101.9.0
-  - @pnpm/workspace.projects-sorter@1100.0.14
@@ -1,16 +0,0 @@
-## 1102.0.14
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/bins.linker@1100.0.25
-  - @pnpm/config.reader@1101.16.0
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/deps.graph-hasher@1100.2.15
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/exec.lifecycle@1100.1.11
-  - @pnpm/patching.apply-patch@1100.0.5
-  - @pnpm/pkg-manifest.reader@1100.0.15
-  - @pnpm/store.controller-types@1101.1.0
-  - @pnpm/types@1101.9.0
@@ -1,6 +0,0 @@
-## 1100.0.14
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/types@1101.9.0
@@ -1,8 +0,0 @@
-## 1100.0.18
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/config.version-policy@1100.1.12
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/types@1101.9.0
@@ -1,10 +0,0 @@
-## 1100.0.36
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/config.reader@1101.16.0
-  - @pnpm/constants@1101.0.0
-  - @pnpm/resolving.npm-resolver@1103.1.0
-  - @pnpm/store.cafs@1100.1.18
-  - @pnpm/store.index@1100.2.3
@@ -1,11 +0,0 @@
-## 1100.0.37
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/cache.api@1100.0.36
-  - @pnpm/cli.utils@1101.0.22
-  - @pnpm/config.reader@1101.16.0
-  - @pnpm/constants@1101.0.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/store.path@1100.0.4
@@ -1,6 +0,0 @@
-## 1100.0.4
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/error@1100.1.1
@@ -1,6 +0,0 @@
-## 1100.0.35
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/config.reader@1101.16.0
@@ -1,10 +0,0 @@
-## 1100.3.15
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/cli.meta@1100.0.14
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/deps.inspection.peers-issues-renderer@1100.0.12
-  - @pnpm/error@1100.1.1
-  - @pnpm/types@1101.9.0
@@ -1,6 +0,0 @@
-## 1100.0.14
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/types@1101.9.0
@@ -1,7 +0,0 @@
-## 1100.1.8
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/error@1100.1.1
-  - @pnpm/workspace.root-finder@1100.0.5
@@ -1,11 +0,0 @@
-## 1101.0.22
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/cli.meta@1100.0.14
-  - @pnpm/config.package-is-installable@1100.1.2
-  - @pnpm/error@1100.1.1
-  - @pnpm/pkg-manifest.utils@1100.3.1
-  - @pnpm/types@1101.9.0
-  - @pnpm/workspace.project-manifest-reader@1100.0.23
@@ -1,11 +0,0 @@
-## 1100.0.36
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/cli.utils@1101.0.22
-  - @pnpm/config.reader@1101.16.0
-  - @pnpm/constants@1101.0.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/object.property-path@1100.1.3
-  - @pnpm/workspace.workspace-manifest-writer@1100.0.21
@@ -1,11 +0,0 @@
-## 1100.1.0
-
-### Minor Changes
-
- Fixed the order in which pnpm matches a lockfile's recorded tarball URL against known registry URLs. Two registry URLs of equal length were previously ordered arbitrarily, so which one a tarball URL matched could differ between runs.
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/constants@1101.0.0
-  - @pnpm/types@1101.9.0
@@ -1,10 +0,0 @@
-## 1100.1.2
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/cli.meta@1100.0.14
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/engine.runtime.system-version@1100.0.9
-  - @pnpm/error@1100.1.1
-  - @pnpm/types@1101.9.0
@@ -1,6 +0,0 @@
-## 1100.1.2
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/error@1100.1.1
@@ -1,10 +0,0 @@
-## 1100.1.0
-
-### Minor Changes
-
- Fixed the order in which pnpm matches a lockfile's recorded tarball URL against known registry URLs. Two registry URLs of equal length were previously ordered arbitrarily, so which one a tarball URL matched could differ between runs.
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/types@1101.9.0
@@ -1,73 +0,0 @@
-## 1101.16.0
-
-### Minor Changes
-
- Fixed the order in which pnpm matches a lockfile's recorded tarball URL against known registry URLs. Two registry URLs of equal length were previously ordered arbitrarily, so which one a tarball URL matched could differ between runs.
-
- **Security fix.** Affects projects using `namedRegistries` on pnpm 11.1.0–11.19.x. It is **semi-breaking** for those projects — see "If you use named registries" below.
-
-  The lockfile recorded no marker for which registry a package came from. Packages were keyed by `name@version` alone, and entry lookup went through `refToRelative(ref, name)`, so a dependency you declared against one registry could be satisfied by an entry that was actually resolved from another. When two registries served the same name and version, both collapsed onto a single `packages:` entry and whichever resolved first decided the tarball every consumer got.
-
-  That is a package-substitution risk: a package you expect from your private registry could be installed from a different registry that publishes the same name and version, and the lockfile recorded nothing that would let you tell.
-
-  Packages resolved from a named registry are now recorded under registry-qualified keys (`<name>@<registryName>:<version>`, e.g. `foo@work:1.0.0`), so each registry gets its own entry and the lockfile pins which one a dependency came from.
-
-  The lockfile format version is unchanged. Registry-qualified keys appear only for packages resolved from a named registry, so a project that does not use `namedRegistries` sees no difference, and older pnpm versions keep reading the file.
-
-  ### If you use named registries
-
-  Your next non-frozen install re-keys those entries, which shows up as a lockfile diff. Commit it — that diff is the fix being applied. Review it: an entry that moves to a registry you did not expect is worth investigating.
-
-  Everyone working on the project should be on this version or newer before you do. An older pnpm reads the re-keyed lockfile fine — frozen installs are unaffected — but it does not produce registry-qualified keys itself, so any install that updates the lockfile writes those entries back to the old shape, and the next install on a current pnpm re-qualifies them. The result is a lockfile that flips back and forth, and while it is in the old shape the project is exposed again. Because the lockfile format version is deliberately unchanged, pnpm cannot detect this and warn you about it.
-
-  There is no setting to keep the old behavior: the old shape is the vulnerability.
-
-  Tarball URLs that follow the standard registry layout are no longer written to the lockfile for named-registry packages; they are recomputed from the `namedRegistries` setting on demand.
-
-  To use named registries, map your aliases in `pnpm-workspace.yaml`:
-
-  ```yaml
-  namedRegistries:
-    work: https://npm.enterprise.example.com/
-  ```
-
-  ### New built-in `npmjs:` alias
-
-  `npmjs:` now resolves to `https://registry.npmjs.org/` with no configuration, alongside the existing `gh:` alias for GitHub Packages. It pins a dependency to the public registry even when `registry` points elsewhere, such as an internal proxy:
-
-  ```json
-  { "dependencies": { "left-pad": "npmjs:^1.3.0" } }
-  ```
-
-  `npm:` cannot do this — it is the alias protocol (`npm:<name>@<range>`) and resolves through whatever `registry` points at.
-
-  **If you mirror or proxy npmjs, point the alias at your mirror:**
-
-  ```yaml
-  namedRegistries:
-    npmjs: https://npm.internal.example.com/
-  ```
-
-  Built-in registry URLs are also the prefixes a lockfile's recorded tarball URL is matched against when pnpm verifies a package. Without the override, an entry whose tarball URL is on `registry.npmjs.org` is verified against the public registry rather than your mirror. This only affects lockfiles that record such URLs — a canonical URL for your configured registry is omitted from the lockfile and unaffected — and only when a tarball-URL, `minimumReleaseAge`, or `trustPolicy` check runs. Overriding the alias is the same escape hatch GHES users already have for `gh`.
-
-  Every alias the lockfile references must stay in `namedRegistries`: reading an entry whose alias is gone fails with `ERR_PNPM_MISSING_NAMED_REGISTRY` rather than silently falling back to the default registry, since that would fetch a different package. Renaming an alias re-resolves the packages that used it.
-
-  Named registry aliases that shadow a reserved dependency specifier prefix (`file`, `link`, `workspace`, `runtime`, `npm`, `jsr`, ...) are now rejected with `ERR_PNPM_RESERVED_NAMED_REGISTRY_NAME` instead of being silently shadowed by the corresponding resolver.
-
-  `pnpm licenses` and `pnpm sbom` now keep the two artifacts apart as well: license records carry the registry alias, and SBOM components carry the purl `repository_url` qualifier.
-
-### Patch Changes
-
- An empty `http-proxy`, `https-proxy`, `proxy`, or `no-proxy` value — from the `.npmrc`, `pnpm-workspace.yaml`, the CLI, or the `HTTP_PROXY` / `HTTPS_PROXY` / `PROXY` / `NO_PROXY` environment variables — no longer fails the install with `ERR_PNPM_INVALID_PROXY`. Empty settings read as unset, so a shell exporting `HTTP_PROXY=` disables the proxy, and an empty `proxy=` in the `.npmrc` no longer suppresses `HTTPS_PROXY` [#13533](https://github.com/pnpm/pnpm/issues/13533).
-
-  `proxy=false` in the `.npmrc` or `proxy: false` in `pnpm-workspace.yaml` now turns proxying off instead of being read as a proxy host named `false`. `false` and `null` on `https-proxy` / `http-proxy` / `no-proxy` read as unset, and on the command line they are ordinary host names, since a flag carries its value verbatim.
-
- Updated dependencies:
-  - @pnpm/catalogs.config@1100.0.4
-  - @pnpm/constants@1101.0.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/hooks.pnpmfile@1100.0.25
-  - @pnpm/pkg-manifest.utils@1100.3.1
-  - @pnpm/types@1101.9.0
-  - @pnpm/workspace.project-manifest-reader@1100.0.23
-  - @pnpm/workspace.workspace-manifest-reader@1100.1.5
@@ -1,5 +0,0 @@
-## 1100.0.0
-
-### Patch Changes
-
- `lexCompare` and `nerfDart` are now published as `@pnpm/text.ordinal-comparator` and `@pnpm/config.registry-auth-key`. Use these instead of `@pnpm/util.lex-comparator` and `@pnpm/config.nerf-dart`.
@@ -1,7 +0,0 @@
-## 1100.1.12
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/error@1100.1.1
-  - @pnpm/types@1101.9.0
@@ -1,7 +0,0 @@
-## 1100.0.21
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/types@1101.9.0
-  - @pnpm/workspace.workspace-manifest-writer@1100.0.21
@@ -1,59 +0,0 @@
-## 1101.0.0
-
-### Major Changes
-
- Fixed the order in which pnpm matches a lockfile's recorded tarball URL against known registry URLs. Two registry URLs of equal length were previously ordered arbitrarily, so which one a tarball URL matched could differ between runs.
-
-### Minor Changes
-
- **Security fix.** Affects projects using `namedRegistries` on pnpm 11.1.0–11.19.x. It is **semi-breaking** for those projects — see "If you use named registries" below.
-
-  The lockfile recorded no marker for which registry a package came from. Packages were keyed by `name@version` alone, and entry lookup went through `refToRelative(ref, name)`, so a dependency you declared against one registry could be satisfied by an entry that was actually resolved from another. When two registries served the same name and version, both collapsed onto a single `packages:` entry and whichever resolved first decided the tarball every consumer got.
-
-  That is a package-substitution risk: a package you expect from your private registry could be installed from a different registry that publishes the same name and version, and the lockfile recorded nothing that would let you tell.
-
-  Packages resolved from a named registry are now recorded under registry-qualified keys (`<name>@<registryName>:<version>`, e.g. `foo@work:1.0.0`), so each registry gets its own entry and the lockfile pins which one a dependency came from.
-
-  The lockfile format version is unchanged. Registry-qualified keys appear only for packages resolved from a named registry, so a project that does not use `namedRegistries` sees no difference, and older pnpm versions keep reading the file.
-
-  ### If you use named registries
-
-  Your next non-frozen install re-keys those entries, which shows up as a lockfile diff. Commit it — that diff is the fix being applied. Review it: an entry that moves to a registry you did not expect is worth investigating.
-
-  Everyone working on the project should be on this version or newer before you do. An older pnpm reads the re-keyed lockfile fine — frozen installs are unaffected — but it does not produce registry-qualified keys itself, so any install that updates the lockfile writes those entries back to the old shape, and the next install on a current pnpm re-qualifies them. The result is a lockfile that flips back and forth, and while it is in the old shape the project is exposed again. Because the lockfile format version is deliberately unchanged, pnpm cannot detect this and warn you about it.
-
-  There is no setting to keep the old behavior: the old shape is the vulnerability.
-
-  Tarball URLs that follow the standard registry layout are no longer written to the lockfile for named-registry packages; they are recomputed from the `namedRegistries` setting on demand.
-
-  To use named registries, map your aliases in `pnpm-workspace.yaml`:
-
-  ```yaml
-  namedRegistries:
-    work: https://npm.enterprise.example.com/
-  ```
-
-  ### New built-in `npmjs:` alias
-
-  `npmjs:` now resolves to `https://registry.npmjs.org/` with no configuration, alongside the existing `gh:` alias for GitHub Packages. It pins a dependency to the public registry even when `registry` points elsewhere, such as an internal proxy:
-
-  ```json
-  { "dependencies": { "left-pad": "npmjs:^1.3.0" } }
-  ```
-
-  `npm:` cannot do this — it is the alias protocol (`npm:<name>@<range>`) and resolves through whatever `registry` points at.
-
-  **If you mirror or proxy npmjs, point the alias at your mirror:**
-
-  ```yaml
-  namedRegistries:
-    npmjs: https://npm.internal.example.com/
-  ```
-
-  Built-in registry URLs are also the prefixes a lockfile's recorded tarball URL is matched against when pnpm verifies a package. Without the override, an entry whose tarball URL is on `registry.npmjs.org` is verified against the public registry rather than your mirror. This only affects lockfiles that record such URLs — a canonical URL for your configured registry is omitted from the lockfile and unaffected — and only when a tarball-URL, `minimumReleaseAge`, or `trustPolicy` check runs. Overriding the alias is the same escape hatch GHES users already have for `gh`.
-
-  Every alias the lockfile references must stay in `namedRegistries`: reading an entry whose alias is gone fails with `ERR_PNPM_MISSING_NAMED_REGISTRY` rather than silently falling back to the default registry, since that would fetch a different package. Renaming an alias re-resolves the packages that used it.
-
-  Named registry aliases that shadow a reserved dependency specifier prefix (`file`, `link`, `workspace`, `runtime`, `npm`, `jsr`, ...) are now rejected with `ERR_PNPM_RESERVED_NAMED_REGISTRY_NAME` instead of being silently shadowed by the corresponding resolver.
-
-  `pnpm licenses` and `pnpm sbom` now keep the two artifacts apart as well: license records carry the registry alias, and SBOM components carry the purl `repository_url` qualifier.
@@ -1,6 +0,0 @@
-## 1100.3.2
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/types@1101.9.0
@@ -1,6 +0,0 @@
-## 1100.0.3
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/error@1100.1.1
@@ -1,6 +0,0 @@
-## 1100.1.5
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/error@1100.1.1
@@ -1,14 +0,0 @@
-## 1101.0.29
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/lockfile.detect-dep-types@1100.0.19
-  - @pnpm/lockfile.fs@1100.2.0
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/lockfile.utils@1101.0.0
-  - @pnpm/lockfile.walker@1100.0.19
-  - @pnpm/network.fetch@1100.1.11
-  - @pnpm/types@1101.9.0
@@ -1,80 +0,0 @@
-## 1101.6.0
-
-### Minor Changes
-
- **Security fix.** Affects projects using `namedRegistries` on pnpm 11.1.0–11.19.x. It is **semi-breaking** for those projects — see "If you use named registries" below.
-
-  The lockfile recorded no marker for which registry a package came from. Packages were keyed by `name@version` alone, and entry lookup went through `refToRelative(ref, name)`, so a dependency you declared against one registry could be satisfied by an entry that was actually resolved from another. When two registries served the same name and version, both collapsed onto a single `packages:` entry and whichever resolved first decided the tarball every consumer got.
-
-  That is a package-substitution risk: a package you expect from your private registry could be installed from a different registry that publishes the same name and version, and the lockfile recorded nothing that would let you tell.
-
-  Packages resolved from a named registry are now recorded under registry-qualified keys (`<name>@<registryName>:<version>`, e.g. `foo@work:1.0.0`), so each registry gets its own entry and the lockfile pins which one a dependency came from.
-
-  The lockfile format version is unchanged. Registry-qualified keys appear only for packages resolved from a named registry, so a project that does not use `namedRegistries` sees no difference, and older pnpm versions keep reading the file.
-
-  ### If you use named registries
-
-  Your next non-frozen install re-keys those entries, which shows up as a lockfile diff. Commit it — that diff is the fix being applied. Review it: an entry that moves to a registry you did not expect is worth investigating.
-
-  Everyone working on the project should be on this version or newer before you do. An older pnpm reads the re-keyed lockfile fine — frozen installs are unaffected — but it does not produce registry-qualified keys itself, so any install that updates the lockfile writes those entries back to the old shape, and the next install on a current pnpm re-qualifies them. The result is a lockfile that flips back and forth, and while it is in the old shape the project is exposed again. Because the lockfile format version is deliberately unchanged, pnpm cannot detect this and warn you about it.
-
-  There is no setting to keep the old behavior: the old shape is the vulnerability.
-
-  Tarball URLs that follow the standard registry layout are no longer written to the lockfile for named-registry packages; they are recomputed from the `namedRegistries` setting on demand.
-
-  To use named registries, map your aliases in `pnpm-workspace.yaml`:
-
-  ```yaml
-  namedRegistries:
-    work: https://npm.enterprise.example.com/
-  ```
-
-  ### New built-in `npmjs:` alias
-
-  `npmjs:` now resolves to `https://registry.npmjs.org/` with no configuration, alongside the existing `gh:` alias for GitHub Packages. It pins a dependency to the public registry even when `registry` points elsewhere, such as an internal proxy:
-
-  ```json
-  { "dependencies": { "left-pad": "npmjs:^1.3.0" } }
-  ```
-
-  `npm:` cannot do this — it is the alias protocol (`npm:<name>@<range>`) and resolves through whatever `registry` points at.
-
-  **If you mirror or proxy npmjs, point the alias at your mirror:**
-
-  ```yaml
-  namedRegistries:
-    npmjs: https://npm.internal.example.com/
-  ```
-
-  Built-in registry URLs are also the prefixes a lockfile's recorded tarball URL is matched against when pnpm verifies a package. Without the override, an entry whose tarball URL is on `registry.npmjs.org` is verified against the public registry rather than your mirror. This only affects lockfiles that record such URLs — a canonical URL for your configured registry is omitted from the lockfile and unaffected — and only when a tarball-URL, `minimumReleaseAge`, or `trustPolicy` check runs. Overriding the alias is the same escape hatch GHES users already have for `gh`.
-
-  Every alias the lockfile references must stay in `namedRegistries`: reading an entry whose alias is gone fails with `ERR_PNPM_MISSING_NAMED_REGISTRY` rather than silently falling back to the default registry, since that would fetch a different package. Renaming an alias re-resolves the packages that used it.
-
-  Named registry aliases that shadow a reserved dependency specifier prefix (`file`, `link`, `workspace`, `runtime`, `npm`, `jsr`, ...) are now rejected with `ERR_PNPM_RESERVED_NAMED_REGISTRY_NAME` instead of being silently shadowed by the corresponding resolver.
-
-  `pnpm licenses` and `pnpm sbom` now keep the two artifacts apart as well: license records carry the registry alias, and SBOM components carry the purl `repository_url` qualifier.
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/cli.meta@1100.0.14
-  - @pnpm/cli.utils@1101.0.22
-  - @pnpm/config.pick-registry-for-package@1100.1.0
-  - @pnpm/config.reader@1101.16.0
-  - @pnpm/config.version-policy@1100.1.12
-  - @pnpm/config.writer@1100.0.21
-  - @pnpm/constants@1101.0.0
-  - @pnpm/deps.compliance.audit@1101.0.29
-  - @pnpm/deps.compliance.license-scanner@1100.1.0
-  - @pnpm/deps.compliance.sbom@1100.4.0
-  - @pnpm/deps.security.signatures@1101.2.10
-  - @pnpm/error@1100.1.1
-  - @pnpm/installing.commands@1100.13.0
-  - @pnpm/lockfile.fs@1100.2.0
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/lockfile.utils@1101.0.0
-  - @pnpm/lockfile.walker@1100.0.19
-  - @pnpm/network.auth-header@1101.1.9
-  - @pnpm/store.path@1100.0.4
-  - @pnpm/types@1101.9.0
-  - @pnpm/workspace.project-manifest-reader@1100.0.23
@@ -1,71 +0,0 @@
-## 1100.1.0
-
-### Minor Changes
-
- **Security fix.** Affects projects using `namedRegistries` on pnpm 11.1.0–11.19.x. It is **semi-breaking** for those projects — see "If you use named registries" below.
-
-  The lockfile recorded no marker for which registry a package came from. Packages were keyed by `name@version` alone, and entry lookup went through `refToRelative(ref, name)`, so a dependency you declared against one registry could be satisfied by an entry that was actually resolved from another. When two registries served the same name and version, both collapsed onto a single `packages:` entry and whichever resolved first decided the tarball every consumer got.
-
-  That is a package-substitution risk: a package you expect from your private registry could be installed from a different registry that publishes the same name and version, and the lockfile recorded nothing that would let you tell.
-
-  Packages resolved from a named registry are now recorded under registry-qualified keys (`<name>@<registryName>:<version>`, e.g. `foo@work:1.0.0`), so each registry gets its own entry and the lockfile pins which one a dependency came from.
-
-  The lockfile format version is unchanged. Registry-qualified keys appear only for packages resolved from a named registry, so a project that does not use `namedRegistries` sees no difference, and older pnpm versions keep reading the file.
-
-  ### If you use named registries
-
-  Your next non-frozen install re-keys those entries, which shows up as a lockfile diff. Commit it — that diff is the fix being applied. Review it: an entry that moves to a registry you did not expect is worth investigating.
-
-  Everyone working on the project should be on this version or newer before you do. An older pnpm reads the re-keyed lockfile fine — frozen installs are unaffected — but it does not produce registry-qualified keys itself, so any install that updates the lockfile writes those entries back to the old shape, and the next install on a current pnpm re-qualifies them. The result is a lockfile that flips back and forth, and while it is in the old shape the project is exposed again. Because the lockfile format version is deliberately unchanged, pnpm cannot detect this and warn you about it.
-
-  There is no setting to keep the old behavior: the old shape is the vulnerability.
-
-  Tarball URLs that follow the standard registry layout are no longer written to the lockfile for named-registry packages; they are recomputed from the `namedRegistries` setting on demand.
-
-  To use named registries, map your aliases in `pnpm-workspace.yaml`:
-
-  ```yaml
-  namedRegistries:
-    work: https://npm.enterprise.example.com/
-  ```
-
-  ### New built-in `npmjs:` alias
-
-  `npmjs:` now resolves to `https://registry.npmjs.org/` with no configuration, alongside the existing `gh:` alias for GitHub Packages. It pins a dependency to the public registry even when `registry` points elsewhere, such as an internal proxy:
-
-  ```json
-  { "dependencies": { "left-pad": "npmjs:^1.3.0" } }
-  ```
-
-  `npm:` cannot do this — it is the alias protocol (`npm:<name>@<range>`) and resolves through whatever `registry` points at.
-
-  **If you mirror or proxy npmjs, point the alias at your mirror:**
-
-  ```yaml
-  namedRegistries:
-    npmjs: https://npm.internal.example.com/
-  ```
-
-  Built-in registry URLs are also the prefixes a lockfile's recorded tarball URL is matched against when pnpm verifies a package. Without the override, an entry whose tarball URL is on `registry.npmjs.org` is verified against the public registry rather than your mirror. This only affects lockfiles that record such URLs — a canonical URL for your configured registry is omitted from the lockfile and unaffected — and only when a tarball-URL, `minimumReleaseAge`, or `trustPolicy` check runs. Overriding the alias is the same escape hatch GHES users already have for `gh`.
-
-  Every alias the lockfile references must stay in `namedRegistries`: reading an entry whose alias is gone fails with `ERR_PNPM_MISSING_NAMED_REGISTRY` rather than silently falling back to the default registry, since that would fetch a different package. Renaming an alias re-resolves the packages that used it.
-
-  Named registry aliases that shadow a reserved dependency specifier prefix (`file`, `link`, `workspace`, `runtime`, `npm`, `jsr`, ...) are now rejected with `ERR_PNPM_RESERVED_NAMED_REGISTRY_NAME` instead of being silently shadowed by the corresponding resolver.
-
-  `pnpm licenses` and `pnpm sbom` now keep the two artifacts apart as well: license records carry the registry alias, and SBOM components carry the purl `repository_url` qualifier.
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/config.package-is-installable@1100.1.2
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/lockfile.detect-dep-types@1100.0.19
-  - @pnpm/lockfile.fs@1100.2.0
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/lockfile.utils@1101.0.0
-  - @pnpm/lockfile.walker@1100.0.19
-  - @pnpm/pkg-manifest.reader@1100.0.15
-  - @pnpm/store.index@1100.2.3
-  - @pnpm/store.pkg-finder@1100.0.28
-  - @pnpm/types@1101.9.0
@@ -1,73 +0,0 @@
-## 1100.4.0
-
-### Minor Changes
-
- **Security fix.** Affects projects using `namedRegistries` on pnpm 11.1.0–11.19.x. It is **semi-breaking** for those projects — see "If you use named registries" below.
-
-  The lockfile recorded no marker for which registry a package came from. Packages were keyed by `name@version` alone, and entry lookup went through `refToRelative(ref, name)`, so a dependency you declared against one registry could be satisfied by an entry that was actually resolved from another. When two registries served the same name and version, both collapsed onto a single `packages:` entry and whichever resolved first decided the tarball every consumer got.
-
-  That is a package-substitution risk: a package you expect from your private registry could be installed from a different registry that publishes the same name and version, and the lockfile recorded nothing that would let you tell.
-
-  Packages resolved from a named registry are now recorded under registry-qualified keys (`<name>@<registryName>:<version>`, e.g. `foo@work:1.0.0`), so each registry gets its own entry and the lockfile pins which one a dependency came from.
-
-  The lockfile format version is unchanged. Registry-qualified keys appear only for packages resolved from a named registry, so a project that does not use `namedRegistries` sees no difference, and older pnpm versions keep reading the file.
-
-  ### If you use named registries
-
-  Your next non-frozen install re-keys those entries, which shows up as a lockfile diff. Commit it — that diff is the fix being applied. Review it: an entry that moves to a registry you did not expect is worth investigating.
-
-  Everyone working on the project should be on this version or newer before you do. An older pnpm reads the re-keyed lockfile fine — frozen installs are unaffected — but it does not produce registry-qualified keys itself, so any install that updates the lockfile writes those entries back to the old shape, and the next install on a current pnpm re-qualifies them. The result is a lockfile that flips back and forth, and while it is in the old shape the project is exposed again. Because the lockfile format version is deliberately unchanged, pnpm cannot detect this and warn you about it.
-
-  There is no setting to keep the old behavior: the old shape is the vulnerability.
-
-  Tarball URLs that follow the standard registry layout are no longer written to the lockfile for named-registry packages; they are recomputed from the `namedRegistries` setting on demand.
-
-  To use named registries, map your aliases in `pnpm-workspace.yaml`:
-
-  ```yaml
-  namedRegistries:
-    work: https://npm.enterprise.example.com/
-  ```
-
-  ### New built-in `npmjs:` alias
-
-  `npmjs:` now resolves to `https://registry.npmjs.org/` with no configuration, alongside the existing `gh:` alias for GitHub Packages. It pins a dependency to the public registry even when `registry` points elsewhere, such as an internal proxy:
-
-  ```json
-  { "dependencies": { "left-pad": "npmjs:^1.3.0" } }
-  ```
-
-  `npm:` cannot do this — it is the alias protocol (`npm:<name>@<range>`) and resolves through whatever `registry` points at.
-
-  **If you mirror or proxy npmjs, point the alias at your mirror:**
-
-  ```yaml
-  namedRegistries:
-    npmjs: https://npm.internal.example.com/
-  ```
-
-  Built-in registry URLs are also the prefixes a lockfile's recorded tarball URL is matched against when pnpm verifies a package. Without the override, an entry whose tarball URL is on `registry.npmjs.org` is verified against the public registry rather than your mirror. This only affects lockfiles that record such URLs — a canonical URL for your configured registry is omitted from the lockfile and unaffected — and only when a tarball-URL, `minimumReleaseAge`, or `trustPolicy` check runs. Overriding the alias is the same escape hatch GHES users already have for `gh`.
-
-  Every alias the lockfile references must stay in `namedRegistries`: reading an entry whose alias is gone fails with `ERR_PNPM_MISSING_NAMED_REGISTRY` rather than silently falling back to the default registry, since that would fetch a different package. Renaming an alias re-resolves the packages that used it.
-
-  Named registry aliases that shadow a reserved dependency specifier prefix (`file`, `link`, `workspace`, `runtime`, `npm`, `jsr`, ...) are now rejected with `ERR_PNPM_RESERVED_NAMED_REGISTRY_NAME` instead of being silently shadowed by the corresponding resolver.
-
-  `pnpm licenses` and `pnpm sbom` now keep the two artifacts apart as well: license records carry the registry alias, and SBOM components carry the purl `repository_url` qualifier.
-
-### Patch Changes
-
- Fixed the order in which pnpm matches a lockfile's recorded tarball URL against known registry URLs. Two registry URLs of equal length were previously ordered arbitrarily, so which one a tarball URL matched could differ between runs.
-
- Updated dependencies:
-  - @pnpm/config.normalize-registries@1100.1.0
-  - @pnpm/constants@1101.0.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/lockfile.detect-dep-types@1100.0.19
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/lockfile.utils@1101.0.0
-  - @pnpm/lockfile.walker@1100.0.19
-  - @pnpm/pkg-manifest.reader@1100.0.15
-  - @pnpm/resolving.resolver-base@1101.1.0
-  - @pnpm/store.index@1100.2.3
-  - @pnpm/store.pkg-finder@1100.0.28
-  - @pnpm/types@1101.9.0
@@ -1,7 +0,0 @@
-## 1100.1.3
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/error@1100.1.1
-  - @pnpm/resolving.git-resolver@1100.1.15
@@ -1,72 +0,0 @@
-## 1100.2.0
-
-### Minor Changes
-
- **Security fix.** Affects projects using `namedRegistries` on pnpm 11.1.0–11.19.x. It is **semi-breaking** for those projects — see "If you use named registries" below.
-
-  The lockfile recorded no marker for which registry a package came from. Packages were keyed by `name@version` alone, and entry lookup went through `refToRelative(ref, name)`, so a dependency you declared against one registry could be satisfied by an entry that was actually resolved from another. When two registries served the same name and version, both collapsed onto a single `packages:` entry and whichever resolved first decided the tarball every consumer got.
-
-  That is a package-substitution risk: a package you expect from your private registry could be installed from a different registry that publishes the same name and version, and the lockfile recorded nothing that would let you tell.
-
-  Packages resolved from a named registry are now recorded under registry-qualified keys (`<name>@<registryName>:<version>`, e.g. `foo@work:1.0.0`), so each registry gets its own entry and the lockfile pins which one a dependency came from.
-
-  The lockfile format version is unchanged. Registry-qualified keys appear only for packages resolved from a named registry, so a project that does not use `namedRegistries` sees no difference, and older pnpm versions keep reading the file.
-
-  ### If you use named registries
-
-  Your next non-frozen install re-keys those entries, which shows up as a lockfile diff. Commit it — that diff is the fix being applied. Review it: an entry that moves to a registry you did not expect is worth investigating.
-
-  Everyone working on the project should be on this version or newer before you do. An older pnpm reads the re-keyed lockfile fine — frozen installs are unaffected — but it does not produce registry-qualified keys itself, so any install that updates the lockfile writes those entries back to the old shape, and the next install on a current pnpm re-qualifies them. The result is a lockfile that flips back and forth, and while it is in the old shape the project is exposed again. Because the lockfile format version is deliberately unchanged, pnpm cannot detect this and warn you about it.
-
-  There is no setting to keep the old behavior: the old shape is the vulnerability.
-
-  Tarball URLs that follow the standard registry layout are no longer written to the lockfile for named-registry packages; they are recomputed from the `namedRegistries` setting on demand.
-
-  To use named registries, map your aliases in `pnpm-workspace.yaml`:
-
-  ```yaml
-  namedRegistries:
-    work: https://npm.enterprise.example.com/
-  ```
-
-  ### New built-in `npmjs:` alias
-
-  `npmjs:` now resolves to `https://registry.npmjs.org/` with no configuration, alongside the existing `gh:` alias for GitHub Packages. It pins a dependency to the public registry even when `registry` points elsewhere, such as an internal proxy:
-
-  ```json
-  { "dependencies": { "left-pad": "npmjs:^1.3.0" } }
-  ```
-
-  `npm:` cannot do this — it is the alias protocol (`npm:<name>@<range>`) and resolves through whatever `registry` points at.
-
-  **If you mirror or proxy npmjs, point the alias at your mirror:**
-
-  ```yaml
-  namedRegistries:
-    npmjs: https://npm.internal.example.com/
-  ```
-
-  Built-in registry URLs are also the prefixes a lockfile's recorded tarball URL is matched against when pnpm verifies a package. Without the override, an entry whose tarball URL is on `registry.npmjs.org` is verified against the public registry rather than your mirror. This only affects lockfiles that record such URLs — a canonical URL for your configured registry is omitted from the lockfile and unaffected — and only when a tarball-URL, `minimumReleaseAge`, or `trustPolicy` check runs. Overriding the alias is the same escape hatch GHES users already have for `gh`.
-
-  Every alias the lockfile references must stay in `namedRegistries`: reading an entry whose alias is gone fails with `ERR_PNPM_MISSING_NAMED_REGISTRY` rather than silently falling back to the default registry, since that would fetch a different package. Renaming an alias re-resolves the packages that used it.
-
-  Named registry aliases that shadow a reserved dependency specifier prefix (`file`, `link`, `workspace`, `runtime`, `npm`, `jsr`, ...) are now rejected with `ERR_PNPM_RESERVED_NAMED_REGISTRY_NAME` instead of being silently shadowed by the corresponding resolver.
-
-  `pnpm licenses` and `pnpm sbom` now keep the two artifacts apart as well: license records carry the registry alias, and SBOM components carry the purl `repository_url` qualifier.
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/config.package-is-installable@1100.1.2
-  - @pnpm/constants@1101.0.0
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/deps.graph-hasher@1100.2.15
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/fs.symlink-dependency@1100.0.17
-  - @pnpm/hooks.types@1100.2.6
-  - @pnpm/installing.modules-yaml@1100.0.15
-  - @pnpm/lockfile.fs@1100.2.0
-  - @pnpm/lockfile.utils@1101.0.0
-  - @pnpm/patching.config@1100.0.15
-  - @pnpm/store.controller-types@1101.1.0
-  - @pnpm/types@1101.9.0
@@ -1,11 +0,0 @@
-## 1100.2.15
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/engine.runtime.system-version@1100.0.9
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/lockfile.utils@1101.0.0
-  - @pnpm/resolving.resolver-base@1101.1.0
-  - @pnpm/types@1101.9.0
@@ -1,26 +0,0 @@
-## 1100.7.3
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/cli.utils@1101.0.22
-  - @pnpm/config.pick-registry-for-package@1100.1.0
-  - @pnpm/config.reader@1101.16.0
-  - @pnpm/deps.github-actions@1100.1.3
-  - @pnpm/deps.inspection.list@1100.1.0
-  - @pnpm/deps.inspection.outdated@1100.1.23
-  - @pnpm/deps.inspection.peers-checker@1100.0.26
-  - @pnpm/deps.inspection.peers-issues-renderer@1100.0.12
-  - @pnpm/error@1100.1.1
-  - @pnpm/global.commands@1100.0.43
-  - @pnpm/global.packages@1100.0.16
-  - @pnpm/installing.modules-yaml@1100.0.15
-  - @pnpm/lockfile.fs@1100.2.0
-  - @pnpm/network.auth-header@1101.1.9
-  - @pnpm/network.fetch@1100.1.11
-  - @pnpm/resolving.default-resolver@1100.3.23
-  - @pnpm/resolving.npm-resolver@1103.1.0
-  - @pnpm/resolving.registry.types@1100.1.9
-  - @pnpm/store.path@1100.0.4
-  - @pnpm/types@1101.9.0
-  - @pnpm/workspace.project-manifest-reader@1100.0.23
@@ -1,64 +0,0 @@
-## 1100.1.0
-
-### Minor Changes
-
- **Security fix.** Affects projects using `namedRegistries` on pnpm 11.1.0–11.19.x. It is **semi-breaking** for those projects — see "If you use named registries" below.
-
-  The lockfile recorded no marker for which registry a package came from. Packages were keyed by `name@version` alone, and entry lookup went through `refToRelative(ref, name)`, so a dependency you declared against one registry could be satisfied by an entry that was actually resolved from another. When two registries served the same name and version, both collapsed onto a single `packages:` entry and whichever resolved first decided the tarball every consumer got.
-
-  That is a package-substitution risk: a package you expect from your private registry could be installed from a different registry that publishes the same name and version, and the lockfile recorded nothing that would let you tell.
-
-  Packages resolved from a named registry are now recorded under registry-qualified keys (`<name>@<registryName>:<version>`, e.g. `foo@work:1.0.0`), so each registry gets its own entry and the lockfile pins which one a dependency came from.
-
-  The lockfile format version is unchanged. Registry-qualified keys appear only for packages resolved from a named registry, so a project that does not use `namedRegistries` sees no difference, and older pnpm versions keep reading the file.
-
-  ### If you use named registries
-
-  Your next non-frozen install re-keys those entries, which shows up as a lockfile diff. Commit it — that diff is the fix being applied. Review it: an entry that moves to a registry you did not expect is worth investigating.
-
-  Everyone working on the project should be on this version or newer before you do. An older pnpm reads the re-keyed lockfile fine — frozen installs are unaffected — but it does not produce registry-qualified keys itself, so any install that updates the lockfile writes those entries back to the old shape, and the next install on a current pnpm re-qualifies them. The result is a lockfile that flips back and forth, and while it is in the old shape the project is exposed again. Because the lockfile format version is deliberately unchanged, pnpm cannot detect this and warn you about it.
-
-  There is no setting to keep the old behavior: the old shape is the vulnerability.
-
-  Tarball URLs that follow the standard registry layout are no longer written to the lockfile for named-registry packages; they are recomputed from the `namedRegistries` setting on demand.
-
-  To use named registries, map your aliases in `pnpm-workspace.yaml`:
-
-  ```yaml
-  namedRegistries:
-    work: https://npm.enterprise.example.com/
-  ```
-
-  ### New built-in `npmjs:` alias
-
-  `npmjs:` now resolves to `https://registry.npmjs.org/` with no configuration, alongside the existing `gh:` alias for GitHub Packages. It pins a dependency to the public registry even when `registry` points elsewhere, such as an internal proxy:
-
-  ```json
-  { "dependencies": { "left-pad": "npmjs:^1.3.0" } }
-  ```
-
-  `npm:` cannot do this — it is the alias protocol (`npm:<name>@<range>`) and resolves through whatever `registry` points at.
-
-  **If you mirror or proxy npmjs, point the alias at your mirror:**
-
-  ```yaml
-  namedRegistries:
-    npmjs: https://npm.internal.example.com/
-  ```
-
-  Built-in registry URLs are also the prefixes a lockfile's recorded tarball URL is matched against when pnpm verifies a package. Without the override, an entry whose tarball URL is on `registry.npmjs.org` is verified against the public registry rather than your mirror. This only affects lockfiles that record such URLs — a canonical URL for your configured registry is omitted from the lockfile and unaffected — and only when a tarball-URL, `minimumReleaseAge`, or `trustPolicy` check runs. Overriding the alias is the same escape hatch GHES users already have for `gh`.
-
-  Every alias the lockfile references must stay in `namedRegistries`: reading an entry whose alias is gone fails with `ERR_PNPM_MISSING_NAMED_REGISTRY` rather than silently falling back to the default registry, since that would fetch a different package. Renaming an alias re-resolves the packages that used it.
-
-  Named registry aliases that shadow a reserved dependency specifier prefix (`file`, `link`, `workspace`, `runtime`, `npm`, `jsr`, ...) are now rejected with `ERR_PNPM_RESERVED_NAMED_REGISTRY_NAME` instead of being silently shadowed by the corresponding resolver.
-
-  `pnpm licenses` and `pnpm sbom` now keep the two artifacts apart as well: license records carry the registry alias, and SBOM components carry the purl `repository_url` qualifier.
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/deps.inspection.tree-builder@1100.1.0
-  - @pnpm/lockfile.fs@1100.2.0
-  - @pnpm/pkg-manifest.reader@1100.0.15
-  - @pnpm/types@1101.9.0
-  - @pnpm/workspace.project-manifest-reader@1100.0.23
@@ -1,17 +0,0 @@
-## 1100.1.23
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/config.parse-overrides@1100.1.2
-  - @pnpm/config.version-policy@1100.1.12
-  - @pnpm/constants@1101.0.0
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/hooks.read-package-hook@1100.2.2
-  - @pnpm/installing.client@1100.3.2
-  - @pnpm/lockfile.fs@1100.2.0
-  - @pnpm/lockfile.utils@1101.0.0
-  - @pnpm/pkg-manifest.utils@1100.3.1
-  - @pnpm/resolving.npm-resolver@1103.1.0
-  - @pnpm/types@1101.9.0
@@ -1,11 +0,0 @@
-## 1100.0.26
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/config.parse-overrides@1100.1.2
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/lockfile.fs@1100.2.0
-  - @pnpm/lockfile.walker@1100.0.19
-  - @pnpm/types@1101.9.0
@@ -1,6 +0,0 @@
-## 1100.0.12
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/types@1101.9.0
@@ -1,69 +0,0 @@
-## 1100.1.0
-
-### Minor Changes
-
- **Security fix.** Affects projects using `namedRegistries` on pnpm 11.1.0–11.19.x. It is **semi-breaking** for those projects — see "If you use named registries" below.
-
-  The lockfile recorded no marker for which registry a package came from. Packages were keyed by `name@version` alone, and entry lookup went through `refToRelative(ref, name)`, so a dependency you declared against one registry could be satisfied by an entry that was actually resolved from another. When two registries served the same name and version, both collapsed onto a single `packages:` entry and whichever resolved first decided the tarball every consumer got.
-
-  That is a package-substitution risk: a package you expect from your private registry could be installed from a different registry that publishes the same name and version, and the lockfile recorded nothing that would let you tell.
-
-  Packages resolved from a named registry are now recorded under registry-qualified keys (`<name>@<registryName>:<version>`, e.g. `foo@work:1.0.0`), so each registry gets its own entry and the lockfile pins which one a dependency came from.
-
-  The lockfile format version is unchanged. Registry-qualified keys appear only for packages resolved from a named registry, so a project that does not use `namedRegistries` sees no difference, and older pnpm versions keep reading the file.
-
-  ### If you use named registries
-
-  Your next non-frozen install re-keys those entries, which shows up as a lockfile diff. Commit it — that diff is the fix being applied. Review it: an entry that moves to a registry you did not expect is worth investigating.
-
-  Everyone working on the project should be on this version or newer before you do. An older pnpm reads the re-keyed lockfile fine — frozen installs are unaffected — but it does not produce registry-qualified keys itself, so any install that updates the lockfile writes those entries back to the old shape, and the next install on a current pnpm re-qualifies them. The result is a lockfile that flips back and forth, and while it is in the old shape the project is exposed again. Because the lockfile format version is deliberately unchanged, pnpm cannot detect this and warn you about it.
-
-  There is no setting to keep the old behavior: the old shape is the vulnerability.
-
-  Tarball URLs that follow the standard registry layout are no longer written to the lockfile for named-registry packages; they are recomputed from the `namedRegistries` setting on demand.
-
-  To use named registries, map your aliases in `pnpm-workspace.yaml`:
-
-  ```yaml
-  namedRegistries:
-    work: https://npm.enterprise.example.com/
-  ```
-
-  ### New built-in `npmjs:` alias
-
-  `npmjs:` now resolves to `https://registry.npmjs.org/` with no configuration, alongside the existing `gh:` alias for GitHub Packages. It pins a dependency to the public registry even when `registry` points elsewhere, such as an internal proxy:
-
-  ```json
-  { "dependencies": { "left-pad": "npmjs:^1.3.0" } }
-  ```
-
-  `npm:` cannot do this — it is the alias protocol (`npm:<name>@<range>`) and resolves through whatever `registry` points at.
-
-  **If you mirror or proxy npmjs, point the alias at your mirror:**
-
-  ```yaml
-  namedRegistries:
-    npmjs: https://npm.internal.example.com/
-  ```
-
-  Built-in registry URLs are also the prefixes a lockfile's recorded tarball URL is matched against when pnpm verifies a package. Without the override, an entry whose tarball URL is on `registry.npmjs.org` is verified against the public registry rather than your mirror. This only affects lockfiles that record such URLs — a canonical URL for your configured registry is omitted from the lockfile and unaffected — and only when a tarball-URL, `minimumReleaseAge`, or `trustPolicy` check runs. Overriding the alias is the same escape hatch GHES users already have for `gh`.
-
-  Every alias the lockfile references must stay in `namedRegistries`: reading an entry whose alias is gone fails with `ERR_PNPM_MISSING_NAMED_REGISTRY` rather than silently falling back to the default registry, since that would fetch a different package. Renaming an alias re-resolves the packages that used it.
-
-  Named registry aliases that shadow a reserved dependency specifier prefix (`file`, `link`, `workspace`, `runtime`, `npm`, `jsr`, ...) are now rejected with `ERR_PNPM_RESERVED_NAMED_REGISTRY_NAME` instead of being silently shadowed by the corresponding resolver.
-
-  `pnpm licenses` and `pnpm sbom` now keep the two artifacts apart as well: license records carry the registry alias, and SBOM components carry the purl `repository_url` qualifier.
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/config.normalize-registries@1100.1.0
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/installing.modules-yaml@1100.0.15
-  - @pnpm/lockfile.detect-dep-types@1100.0.19
-  - @pnpm/lockfile.fs@1100.2.0
-  - @pnpm/lockfile.utils@1101.0.0
-  - @pnpm/pkg-manifest.reader@1100.0.15
-  - @pnpm/store.cafs@1100.1.18
-  - @pnpm/store.index@1100.2.3
-  - @pnpm/types@1101.9.0
@@ -1,60 +0,0 @@
-## 1100.1.0
-
-### Minor Changes
-
- **Security fix.** Affects projects using `namedRegistries` on pnpm 11.1.0–11.19.x. It is **semi-breaking** for those projects — see "If you use named registries" below.
-
-  The lockfile recorded no marker for which registry a package came from. Packages were keyed by `name@version` alone, and entry lookup went through `refToRelative(ref, name)`, so a dependency you declared against one registry could be satisfied by an entry that was actually resolved from another. When two registries served the same name and version, both collapsed onto a single `packages:` entry and whichever resolved first decided the tarball every consumer got.
-
-  That is a package-substitution risk: a package you expect from your private registry could be installed from a different registry that publishes the same name and version, and the lockfile recorded nothing that would let you tell.
-
-  Packages resolved from a named registry are now recorded under registry-qualified keys (`<name>@<registryName>:<version>`, e.g. `foo@work:1.0.0`), so each registry gets its own entry and the lockfile pins which one a dependency came from.
-
-  The lockfile format version is unchanged. Registry-qualified keys appear only for packages resolved from a named registry, so a project that does not use `namedRegistries` sees no difference, and older pnpm versions keep reading the file.
-
-  ### If you use named registries
-
-  Your next non-frozen install re-keys those entries, which shows up as a lockfile diff. Commit it — that diff is the fix being applied. Review it: an entry that moves to a registry you did not expect is worth investigating.
-
-  Everyone working on the project should be on this version or newer before you do. An older pnpm reads the re-keyed lockfile fine — frozen installs are unaffected — but it does not produce registry-qualified keys itself, so any install that updates the lockfile writes those entries back to the old shape, and the next install on a current pnpm re-qualifies them. The result is a lockfile that flips back and forth, and while it is in the old shape the project is exposed again. Because the lockfile format version is deliberately unchanged, pnpm cannot detect this and warn you about it.
-
-  There is no setting to keep the old behavior: the old shape is the vulnerability.
-
-  Tarball URLs that follow the standard registry layout are no longer written to the lockfile for named-registry packages; they are recomputed from the `namedRegistries` setting on demand.
-
-  To use named registries, map your aliases in `pnpm-workspace.yaml`:
-
-  ```yaml
-  namedRegistries:
-    work: https://npm.enterprise.example.com/
-  ```
-
-  ### New built-in `npmjs:` alias
-
-  `npmjs:` now resolves to `https://registry.npmjs.org/` with no configuration, alongside the existing `gh:` alias for GitHub Packages. It pins a dependency to the public registry even when `registry` points elsewhere, such as an internal proxy:
-
-  ```json
-  { "dependencies": { "left-pad": "npmjs:^1.3.0" } }
-  ```
-
-  `npm:` cannot do this — it is the alias protocol (`npm:<name>@<range>`) and resolves through whatever `registry` points at.
-
-  **If you mirror or proxy npmjs, point the alias at your mirror:**
-
-  ```yaml
-  namedRegistries:
-    npmjs: https://npm.internal.example.com/
-  ```
-
-  Built-in registry URLs are also the prefixes a lockfile's recorded tarball URL is matched against when pnpm verifies a package. Without the override, an entry whose tarball URL is on `registry.npmjs.org` is verified against the public registry rather than your mirror. This only affects lockfiles that record such URLs — a canonical URL for your configured registry is omitted from the lockfile and unaffected — and only when a tarball-URL, `minimumReleaseAge`, or `trustPolicy` check runs. Overriding the alias is the same escape hatch GHES users already have for `gh`.
-
-  Every alias the lockfile references must stay in `namedRegistries`: reading an entry whose alias is gone fails with `ERR_PNPM_MISSING_NAMED_REGISTRY` rather than silently falling back to the default registry, since that would fetch a different package. Renaming an alias re-resolves the packages that used it.
-
-  Named registry aliases that shadow a reserved dependency specifier prefix (`file`, `link`, `workspace`, `runtime`, `npm`, `jsr`, ...) are now rejected with `ERR_PNPM_RESERVED_NAMED_REGISTRY_NAME` instead of being silently shadowed by the corresponding resolver.
-
-  `pnpm licenses` and `pnpm sbom` now keep the two artifacts apart as well: license records carry the registry alias, and SBOM components carry the purl `repository_url` qualifier.
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/types@1101.9.0
@@ -1,7 +0,0 @@
-## 1101.2.10
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/error@1100.1.1
-  - @pnpm/network.fetch@1100.1.11
@@ -1,18 +0,0 @@
-## 1100.1.15
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/config.parse-overrides@1100.1.2
-  - @pnpm/config.reader@1101.16.0
-  - @pnpm/constants@1101.0.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/installing.context@1100.1.0
-  - @pnpm/lockfile.fs@1100.2.0
-  - @pnpm/lockfile.settings-checker@1100.1.10
-  - @pnpm/lockfile.verification@1100.0.31
-  - @pnpm/resolving.resolver-base@1101.1.0
-  - @pnpm/types@1101.9.0
-  - @pnpm/workspace.projects-reader@1101.0.22
-  - @pnpm/workspace.state@1100.0.36
-  - @pnpm/workspace.workspace-manifest-reader@1100.1.5
@@ -1,31 +0,0 @@
-## 1101.3.2
-
-### Patch Changes
-
- The env lockfile no longer pins `@pnpm/exe` alongside `pnpm` when the wanted pnpm version is 12 or newer. From v12 the unscoped `pnpm` package is itself the native executable, so `@pnpm/exe` is not published for it and resolving it would fail. The engine identity check now verifies the native binary through whichever package ships it.
-
- Updated dependencies:
-  - @pnpm/bins.linker@1100.0.25
-  - @pnpm/building.policy@1100.0.18
-  - @pnpm/cli.meta@1100.0.14
-  - @pnpm/cli.utils@1101.0.22
-  - @pnpm/config.pick-registry-for-package@1100.1.0
-  - @pnpm/config.reader@1101.16.0
-  - @pnpm/config.version-policy@1100.1.12
-  - @pnpm/deps.graph-hasher@1100.2.15
-  - @pnpm/deps.security.signatures@1101.2.10
-  - @pnpm/error@1100.1.1
-  - @pnpm/global.commands@1100.0.43
-  - @pnpm/global.packages@1100.0.16
-  - @pnpm/installing.client@1100.3.2
-  - @pnpm/installing.deps-restorer@1102.3.0
-  - @pnpm/installing.env-installer@1102.0.15
-  - @pnpm/lockfile.fs@1100.2.0
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/network.auth-header@1101.1.9
-  - @pnpm/pkg-manifest.utils@1100.3.1
-  - @pnpm/resolving.npm-resolver@1103.1.0
-  - @pnpm/store.connection-manager@1100.3.15
-  - @pnpm/store.controller@1102.0.11
-  - @pnpm/types@1101.9.0
-  - @pnpm/workspace.project-manifest-reader@1100.0.23
@@ -1,12 +0,0 @@
-## 1102.0.14
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/crypto.shasums-file@1100.1.5
-  - @pnpm/error@1100.1.1
-  - @pnpm/fetching.binary-fetcher@1102.0.9
-  - @pnpm/fetching.fetcher-base@1100.2.7
-  - @pnpm/resolving.npm-resolver@1103.1.0
-  - @pnpm/resolving.resolver-base@1101.1.0
-  - @pnpm/types@1101.9.0
@@ -1,11 +0,0 @@
-## 1100.1.19
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/cli.utils@1101.0.22
-  - @pnpm/config.reader@1101.16.0
-  - @pnpm/engine.runtime.node-resolver@1101.1.21
-  - @pnpm/error@1100.1.1
-  - @pnpm/network.fetch@1100.1.11
-  - @pnpm/types@1101.9.0
@@ -1,12 +0,0 @@
-## 1102.0.14
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/crypto.shasums-file@1100.1.5
-  - @pnpm/error@1100.1.1
-  - @pnpm/fetching.binary-fetcher@1102.0.9
-  - @pnpm/fetching.fetcher-base@1100.2.7
-  - @pnpm/resolving.npm-resolver@1103.1.0
-  - @pnpm/resolving.resolver-base@1101.1.0
-  - @pnpm/types@1101.9.0
@@ -1,10 +0,0 @@
-## 1101.1.21
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/config.reader@1101.16.0
-  - @pnpm/crypto.shasums-file@1100.1.5
-  - @pnpm/error@1100.1.1
-  - @pnpm/resolving.resolver-base@1101.1.0
-  - @pnpm/types@1101.9.0
@@ -1,7 +0,0 @@
-## 1100.0.9
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/cli.meta@1100.0.14
-  - @pnpm/types@1101.9.0
@@ -1,6 +0,0 @@
-## 1100.1.1
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/constants@1101.0.0
@@ -1,23 +0,0 @@
-## 1100.4.7
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/bins.resolver@1100.0.14
-  - @pnpm/building.commands@1100.1.20
-  - @pnpm/cli.utils@1101.0.22
-  - @pnpm/config.reader@1101.16.0
-  - @pnpm/config.version-policy@1100.1.12
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/deps.status@1100.1.15
-  - @pnpm/engine.runtime.commands@1100.1.19
-  - @pnpm/error@1100.1.1
-  - @pnpm/exec.lifecycle@1100.1.11
-  - @pnpm/installing.client@1100.3.2
-  - @pnpm/installing.commands@1100.13.0
-  - @pnpm/pkg-manifest.reader@1100.0.15
-  - @pnpm/store.path@1100.0.4
-  - @pnpm/types@1101.9.0
-  - @pnpm/workspace.injected-deps-syncer@1100.0.31
-  - @pnpm/workspace.project-manifest-reader@1100.0.23
-  - @pnpm/workspace.projects-sorter@1100.0.14
@@ -1,12 +0,0 @@
-## 1100.1.11
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/bins.linker@1100.0.25
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/error@1100.1.1
-  - @pnpm/fetching.directory-fetcher@1100.0.28
-  - @pnpm/pkg-manifest.reader@1100.0.15
-  - @pnpm/store.controller-types@1101.1.0
-  - @pnpm/types@1101.9.0
@@ -1,9 +0,0 @@
-## 1100.0.30
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/error@1100.1.1
-  - @pnpm/exec.lifecycle@1100.1.11
-  - @pnpm/pkg-manifest.reader@1100.0.15
-  - @pnpm/types@1101.9.0
@@ -1,8 +0,0 @@
-## 1102.0.9
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/error@1100.1.1
-  - @pnpm/fetching.fetcher-base@1100.2.7
-  - @pnpm/store.index@1100.2.3
@@ -1,10 +0,0 @@
-## 1100.0.28
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/building.pkg-requires-build@1100.0.14
-  - @pnpm/fetching.fetcher-base@1100.2.7
-  - @pnpm/resolving.resolver-base@1101.1.0
-  - @pnpm/types@1101.9.0
-  - @pnpm/workspace.project-manifest-reader@1100.0.23
@@ -1,7 +0,0 @@
-## 1100.2.7
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/resolving.resolver-base@1101.1.0
-  - @pnpm/types@1101.9.0
@@ -1,10 +0,0 @@
-## 1102.0.12
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/error@1100.1.1
-  - @pnpm/exec.prepare-package@1100.0.30
-  - @pnpm/fetching.fetcher-base@1100.2.7
-  - @pnpm/resolving.git-resolver@1100.1.15
-  - @pnpm/store.index@1100.2.3
@@ -1,9 +0,0 @@
-## 1100.1.6
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/error@1100.1.1
-  - @pnpm/fetching.fetcher-base@1100.2.7
-  - @pnpm/hooks.types@1100.2.6
-  - @pnpm/resolving.resolver-base@1101.1.0
@@ -1,11 +0,0 @@
-## 1102.0.12
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/error@1100.1.1
-  - @pnpm/exec.prepare-package@1100.0.30
-  - @pnpm/fetching.fetcher-base@1100.2.7
-  - @pnpm/store.index@1100.2.3
-  - @pnpm/types@1101.9.0
@@ -1,7 +0,0 @@
-## 1100.0.24
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/store.controller-types@1101.1.0
@@ -1,7 +0,0 @@
-## 1100.0.17
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/types@1101.9.0
@@ -1,19 +0,0 @@
-## 1100.0.43
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/bins.linker@1100.0.25
-  - @pnpm/bins.remover@1100.0.19
-  - @pnpm/bins.resolver@1100.0.14
-  - @pnpm/cli.utils@1101.0.22
-  - @pnpm/config.reader@1101.16.0
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/deps.inspection.list@1100.1.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/global.packages@1100.0.16
-  - @pnpm/installing.deps-installer@1103.1.0
-  - @pnpm/pkg-manifest.reader@1100.0.15
-  - @pnpm/pkg-manifest.utils@1100.3.1
-  - @pnpm/store.connection-manager@1100.3.15
-  - @pnpm/types@1101.9.0
@@ -1,8 +0,0 @@
-## 1100.0.16
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/bins.resolver@1100.0.14
-  - @pnpm/pkg-manifest.reader@1100.0.15
-  - @pnpm/types@1101.9.0
@@ -1,11 +0,0 @@
-## 1100.0.25
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/error@1100.1.1
-  - @pnpm/hooks.types@1100.2.6
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/store.controller-types@1101.1.0
-  - @pnpm/types@1101.9.0
@@ -1,8 +0,0 @@
-## 1100.2.2
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/config.parse-overrides@1100.1.2
-  - @pnpm/error@1100.1.1
-  - @pnpm/types@1101.9.0
@@ -1,9 +0,0 @@
-## 1100.2.6
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/fetching.fetcher-base@1100.2.7
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/resolving.resolver-base@1101.1.0
-  - @pnpm/types@1101.9.0
@@ -1,19 +0,0 @@
-## 1100.3.2
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/engine.runtime.node-resolver@1101.1.21
-  - @pnpm/error@1100.1.1
-  - @pnpm/fetching.binary-fetcher@1102.0.9
-  - @pnpm/fetching.directory-fetcher@1100.0.28
-  - @pnpm/fetching.git-fetcher@1102.0.12
-  - @pnpm/fetching.tarball-fetcher@1102.0.12
-  - @pnpm/hooks.types@1100.2.6
-  - @pnpm/network.auth-header@1101.1.9
-  - @pnpm/network.fetch@1100.1.11
-  - @pnpm/resolving.default-resolver@1100.3.23
-  - @pnpm/resolving.npm-resolver@1103.1.0
-  - @pnpm/resolving.resolver-base@1101.1.0
-  - @pnpm/store.index@1100.2.3
-  - @pnpm/types@1101.9.0
@@ -1,102 +0,0 @@
-## 1100.13.0
-
-### Minor Changes
-
- **Security fix.** Affects projects using `namedRegistries` on pnpm 11.1.0–11.19.x. It is **semi-breaking** for those projects — see "If you use named registries" below.
-
-  The lockfile recorded no marker for which registry a package came from. Packages were keyed by `name@version` alone, and entry lookup went through `refToRelative(ref, name)`, so a dependency you declared against one registry could be satisfied by an entry that was actually resolved from another. When two registries served the same name and version, both collapsed onto a single `packages:` entry and whichever resolved first decided the tarball every consumer got.
-
-  That is a package-substitution risk: a package you expect from your private registry could be installed from a different registry that publishes the same name and version, and the lockfile recorded nothing that would let you tell.
-
-  Packages resolved from a named registry are now recorded under registry-qualified keys (`<name>@<registryName>:<version>`, e.g. `foo@work:1.0.0`), so each registry gets its own entry and the lockfile pins which one a dependency came from.
-
-  The lockfile format version is unchanged. Registry-qualified keys appear only for packages resolved from a named registry, so a project that does not use `namedRegistries` sees no difference, and older pnpm versions keep reading the file.
-
-  ### If you use named registries
-
-  Your next non-frozen install re-keys those entries, which shows up as a lockfile diff. Commit it — that diff is the fix being applied. Review it: an entry that moves to a registry you did not expect is worth investigating.
-
-  Everyone working on the project should be on this version or newer before you do. An older pnpm reads the re-keyed lockfile fine — frozen installs are unaffected — but it does not produce registry-qualified keys itself, so any install that updates the lockfile writes those entries back to the old shape, and the next install on a current pnpm re-qualifies them. The result is a lockfile that flips back and forth, and while it is in the old shape the project is exposed again. Because the lockfile format version is deliberately unchanged, pnpm cannot detect this and warn you about it.
-
-  There is no setting to keep the old behavior: the old shape is the vulnerability.
-
-  Tarball URLs that follow the standard registry layout are no longer written to the lockfile for named-registry packages; they are recomputed from the `namedRegistries` setting on demand.
-
-  To use named registries, map your aliases in `pnpm-workspace.yaml`:
-
-  ```yaml
-  namedRegistries:
-    work: https://npm.enterprise.example.com/
-  ```
-
-  ### New built-in `npmjs:` alias
-
-  `npmjs:` now resolves to `https://registry.npmjs.org/` with no configuration, alongside the existing `gh:` alias for GitHub Packages. It pins a dependency to the public registry even when `registry` points elsewhere, such as an internal proxy:
-
-  ```json
-  { "dependencies": { "left-pad": "npmjs:^1.3.0" } }
-  ```
-
-  `npm:` cannot do this — it is the alias protocol (`npm:<name>@<range>`) and resolves through whatever `registry` points at.
-
-  **If you mirror or proxy npmjs, point the alias at your mirror:**
-
-  ```yaml
-  namedRegistries:
-    npmjs: https://npm.internal.example.com/
-  ```
-
-  Built-in registry URLs are also the prefixes a lockfile's recorded tarball URL is matched against when pnpm verifies a package. Without the override, an entry whose tarball URL is on `registry.npmjs.org` is verified against the public registry rather than your mirror. This only affects lockfiles that record such URLs — a canonical URL for your configured registry is omitted from the lockfile and unaffected — and only when a tarball-URL, `minimumReleaseAge`, or `trustPolicy` check runs. Overriding the alias is the same escape hatch GHES users already have for `gh`.
-
-  Every alias the lockfile references must stay in `namedRegistries`: reading an entry whose alias is gone fails with `ERR_PNPM_MISSING_NAMED_REGISTRY` rather than silently falling back to the default registry, since that would fetch a different package. Renaming an alias re-resolves the packages that used it.
-
-  Named registry aliases that shadow a reserved dependency specifier prefix (`file`, `link`, `workspace`, `runtime`, `npm`, `jsr`, ...) are now rejected with `ERR_PNPM_RESERVED_NAMED_REGISTRY_NAME` instead of being silently shadowed by the corresponding resolver.
-
-  `pnpm licenses` and `pnpm sbom` now keep the two artifacts apart as well: license records carry the registry alias, and SBOM components carry the purl `repository_url` qualifier.
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/building.after-install@1102.0.15
-  - @pnpm/building.policy@1100.0.18
-  - @pnpm/catalogs.config@1100.0.4
-  - @pnpm/cli.utils@1101.0.22
-  - @pnpm/config.pick-registry-for-package@1100.1.0
-  - @pnpm/config.reader@1101.16.0
-  - @pnpm/config.version-policy@1100.1.12
-  - @pnpm/config.writer@1100.0.21
-  - @pnpm/constants@1101.0.0
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/deps.github-actions@1100.1.3
-  - @pnpm/deps.inspection.outdated@1100.1.23
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/deps.security.signatures@1101.2.10
-  - @pnpm/deps.status@1100.1.15
-  - @pnpm/error@1100.1.1
-  - @pnpm/global.commands@1100.0.43
-  - @pnpm/hooks.pnpmfile@1100.0.25
-  - @pnpm/installing.context@1100.1.0
-  - @pnpm/installing.dedupe.check@1100.1.8
-  - @pnpm/installing.deps-installer@1103.1.0
-  - @pnpm/installing.env-installer@1102.0.15
-  - @pnpm/lockfile.fs@1100.2.0
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/network.auth-header@1101.1.9
-  - @pnpm/network.fetch@1100.1.11
-  - @pnpm/pkg-manifest.reader@1100.0.15
-  - @pnpm/pkg-manifest.utils@1100.3.1
-  - @pnpm/resolving.npm-resolver@1103.1.0
-  - @pnpm/resolving.resolver-base@1101.1.0
-  - @pnpm/store.connection-manager@1100.3.15
-  - @pnpm/store.controller@1102.0.11
-  - @pnpm/types@1101.9.0
-  - @pnpm/workspace.project-manifest-reader@1100.0.23
-  - @pnpm/workspace.project-manifest-writer@1100.0.14
-  - @pnpm/workspace.projects-filter@1100.0.35
-  - @pnpm/workspace.projects-graph@1100.0.31
-  - @pnpm/workspace.projects-reader@1101.0.22
-  - @pnpm/workspace.projects-sorter@1100.0.14
-  - @pnpm/workspace.root-finder@1100.0.5
-  - @pnpm/workspace.state@1100.0.36
-  - @pnpm/workspace.workspace-manifest-reader@1100.1.5
-  - @pnpm/workspace.workspace-manifest-writer@1100.0.21
@@ -1,68 +0,0 @@
-## 1100.1.0
-
-### Minor Changes
-
- **Security fix.** Affects projects using `namedRegistries` on pnpm 11.1.0–11.19.x. It is **semi-breaking** for those projects — see "If you use named registries" below.
-
-  The lockfile recorded no marker for which registry a package came from. Packages were keyed by `name@version` alone, and entry lookup went through `refToRelative(ref, name)`, so a dependency you declared against one registry could be satisfied by an entry that was actually resolved from another. When two registries served the same name and version, both collapsed onto a single `packages:` entry and whichever resolved first decided the tarball every consumer got.
-
-  That is a package-substitution risk: a package you expect from your private registry could be installed from a different registry that publishes the same name and version, and the lockfile recorded nothing that would let you tell.
-
-  Packages resolved from a named registry are now recorded under registry-qualified keys (`<name>@<registryName>:<version>`, e.g. `foo@work:1.0.0`), so each registry gets its own entry and the lockfile pins which one a dependency came from.
-
-  The lockfile format version is unchanged. Registry-qualified keys appear only for packages resolved from a named registry, so a project that does not use `namedRegistries` sees no difference, and older pnpm versions keep reading the file.
-
-  ### If you use named registries
-
-  Your next non-frozen install re-keys those entries, which shows up as a lockfile diff. Commit it — that diff is the fix being applied. Review it: an entry that moves to a registry you did not expect is worth investigating.
-
-  Everyone working on the project should be on this version or newer before you do. An older pnpm reads the re-keyed lockfile fine — frozen installs are unaffected — but it does not produce registry-qualified keys itself, so any install that updates the lockfile writes those entries back to the old shape, and the next install on a current pnpm re-qualifies them. The result is a lockfile that flips back and forth, and while it is in the old shape the project is exposed again. Because the lockfile format version is deliberately unchanged, pnpm cannot detect this and warn you about it.
-
-  There is no setting to keep the old behavior: the old shape is the vulnerability.
-
-  Tarball URLs that follow the standard registry layout are no longer written to the lockfile for named-registry packages; they are recomputed from the `namedRegistries` setting on demand.
-
-  To use named registries, map your aliases in `pnpm-workspace.yaml`:
-
-  ```yaml
-  namedRegistries:
-    work: https://npm.enterprise.example.com/
-  ```
-
-  ### New built-in `npmjs:` alias
-
-  `npmjs:` now resolves to `https://registry.npmjs.org/` with no configuration, alongside the existing `gh:` alias for GitHub Packages. It pins a dependency to the public registry even when `registry` points elsewhere, such as an internal proxy:
-
-  ```json
-  { "dependencies": { "left-pad": "npmjs:^1.3.0" } }
-  ```
-
-  `npm:` cannot do this — it is the alias protocol (`npm:<name>@<range>`) and resolves through whatever `registry` points at.
-
-  **If you mirror or proxy npmjs, point the alias at your mirror:**
-
-  ```yaml
-  namedRegistries:
-    npmjs: https://npm.internal.example.com/
-  ```
-
-  Built-in registry URLs are also the prefixes a lockfile's recorded tarball URL is matched against when pnpm verifies a package. Without the override, an entry whose tarball URL is on `registry.npmjs.org` is verified against the public registry rather than your mirror. This only affects lockfiles that record such URLs — a canonical URL for your configured registry is omitted from the lockfile and unaffected — and only when a tarball-URL, `minimumReleaseAge`, or `trustPolicy` check runs. Overriding the alias is the same escape hatch GHES users already have for `gh`.
-
-  Every alias the lockfile references must stay in `namedRegistries`: reading an entry whose alias is gone fails with `ERR_PNPM_MISSING_NAMED_REGISTRY` rather than silently falling back to the default registry, since that would fetch a different package. Renaming an alias re-resolves the packages that used it.
-
-  Named registry aliases that shadow a reserved dependency specifier prefix (`file`, `link`, `workspace`, `runtime`, `npm`, `jsr`, ...) are now rejected with `ERR_PNPM_RESERVED_NAMED_REGISTRY_NAME` instead of being silently shadowed by the corresponding resolver.
-
-  `pnpm licenses` and `pnpm sbom` now keep the two artifacts apart as well: license records carry the registry alias, and SBOM components carry the purl `repository_url` qualifier.
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/constants@1101.0.0
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/error@1100.1.1
-  - @pnpm/installing.modules-yaml@1100.0.15
-  - @pnpm/installing.read-projects-context@1100.0.27
-  - @pnpm/lockfile.fs@1100.2.0
-  - @pnpm/resolving.resolver-base@1101.1.0
-  - @pnpm/store.controller@1102.0.11
-  - @pnpm/types@1101.9.0
@@ -1,8 +0,0 @@
-## 1100.1.8
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/error@1100.1.1
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/types@1101.9.0
@@ -1,103 +0,0 @@
-## 1103.1.0
-
-### Minor Changes
-
- **Security fix.** Affects projects using `namedRegistries` on pnpm 11.1.0–11.19.x. It is **semi-breaking** for those projects — see "If you use named registries" below.
-
-  The lockfile recorded no marker for which registry a package came from. Packages were keyed by `name@version` alone, and entry lookup went through `refToRelative(ref, name)`, so a dependency you declared against one registry could be satisfied by an entry that was actually resolved from another. When two registries served the same name and version, both collapsed onto a single `packages:` entry and whichever resolved first decided the tarball every consumer got.
-
-  That is a package-substitution risk: a package you expect from your private registry could be installed from a different registry that publishes the same name and version, and the lockfile recorded nothing that would let you tell.
-
-  Packages resolved from a named registry are now recorded under registry-qualified keys (`<name>@<registryName>:<version>`, e.g. `foo@work:1.0.0`), so each registry gets its own entry and the lockfile pins which one a dependency came from.
-
-  The lockfile format version is unchanged. Registry-qualified keys appear only for packages resolved from a named registry, so a project that does not use `namedRegistries` sees no difference, and older pnpm versions keep reading the file.
-
-  ### If you use named registries
-
-  Your next non-frozen install re-keys those entries, which shows up as a lockfile diff. Commit it — that diff is the fix being applied. Review it: an entry that moves to a registry you did not expect is worth investigating.
-
-  Everyone working on the project should be on this version or newer before you do. An older pnpm reads the re-keyed lockfile fine — frozen installs are unaffected — but it does not produce registry-qualified keys itself, so any install that updates the lockfile writes those entries back to the old shape, and the next install on a current pnpm re-qualifies them. The result is a lockfile that flips back and forth, and while it is in the old shape the project is exposed again. Because the lockfile format version is deliberately unchanged, pnpm cannot detect this and warn you about it.
-
-  There is no setting to keep the old behavior: the old shape is the vulnerability.
-
-  Tarball URLs that follow the standard registry layout are no longer written to the lockfile for named-registry packages; they are recomputed from the `namedRegistries` setting on demand.
-
-  To use named registries, map your aliases in `pnpm-workspace.yaml`:
-
-  ```yaml
-  namedRegistries:
-    work: https://npm.enterprise.example.com/
-  ```
-
-  ### New built-in `npmjs:` alias
-
-  `npmjs:` now resolves to `https://registry.npmjs.org/` with no configuration, alongside the existing `gh:` alias for GitHub Packages. It pins a dependency to the public registry even when `registry` points elsewhere, such as an internal proxy:
-
-  ```json
-  { "dependencies": { "left-pad": "npmjs:^1.3.0" } }
-  ```
-
-  `npm:` cannot do this — it is the alias protocol (`npm:<name>@<range>`) and resolves through whatever `registry` points at.
-
-  **If you mirror or proxy npmjs, point the alias at your mirror:**
-
-  ```yaml
-  namedRegistries:
-    npmjs: https://npm.internal.example.com/
-  ```
-
-  Built-in registry URLs are also the prefixes a lockfile's recorded tarball URL is matched against when pnpm verifies a package. Without the override, an entry whose tarball URL is on `registry.npmjs.org` is verified against the public registry rather than your mirror. This only affects lockfiles that record such URLs — a canonical URL for your configured registry is omitted from the lockfile and unaffected — and only when a tarball-URL, `minimumReleaseAge`, or `trustPolicy` check runs. Overriding the alias is the same escape hatch GHES users already have for `gh`.
-
-  Every alias the lockfile references must stay in `namedRegistries`: reading an entry whose alias is gone fails with `ERR_PNPM_MISSING_NAMED_REGISTRY` rather than silently falling back to the default registry, since that would fetch a different package. Renaming an alias re-resolves the packages that used it.
-
-  Named registry aliases that shadow a reserved dependency specifier prefix (`file`, `link`, `workspace`, `runtime`, `npm`, `jsr`, ...) are now rejected with `ERR_PNPM_RESERVED_NAMED_REGISTRY_NAME` instead of being silently shadowed by the corresponding resolver.
-
-  `pnpm licenses` and `pnpm sbom` now keep the two artifacts apart as well: license records carry the registry alias, and SBOM components carry the purl `repository_url` qualifier.
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/bins.linker@1100.0.25
-  - @pnpm/bins.remover@1100.0.19
-  - @pnpm/building.after-install@1102.0.15
-  - @pnpm/building.during-install@1102.0.14
-  - @pnpm/building.policy@1100.0.18
-  - @pnpm/catalogs.config@1100.0.4
-  - @pnpm/config.normalize-registries@1100.1.0
-  - @pnpm/config.parse-overrides@1100.1.2
-  - @pnpm/config.version-policy@1100.1.12
-  - @pnpm/constants@1101.0.0
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/deps.graph-hasher@1100.2.15
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/exec.lifecycle@1100.1.11
-  - @pnpm/fs.symlink-dependency@1100.0.17
-  - @pnpm/hooks.read-package-hook@1100.2.2
-  - @pnpm/hooks.types@1100.2.6
-  - @pnpm/installing.context@1100.1.0
-  - @pnpm/installing.deps-resolver@1101.1.0
-  - @pnpm/installing.deps-restorer@1102.3.0
-  - @pnpm/installing.linking.direct-dep-linker@1100.0.17
-  - @pnpm/installing.linking.hoist@1100.0.25
-  - @pnpm/installing.linking.modules-cleaner@1100.1.18
-  - @pnpm/installing.modules-yaml@1100.0.15
-  - @pnpm/installing.package-requester@1102.1.9
-  - @pnpm/lockfile.filtering@1100.2.2
-  - @pnpm/lockfile.fs@1100.2.0
-  - @pnpm/lockfile.preferred-versions@1100.0.28
-  - @pnpm/lockfile.pruner@1100.0.19
-  - @pnpm/lockfile.settings-checker@1100.1.10
-  - @pnpm/lockfile.to-pnp@1100.1.12
-  - @pnpm/lockfile.utils@1101.0.0
-  - @pnpm/lockfile.verification@1100.0.31
-  - @pnpm/lockfile.walker@1100.0.19
-  - @pnpm/network.auth-header@1101.1.9
-  - @pnpm/patching.config@1100.0.15
-  - @pnpm/pkg-manifest.utils@1100.3.1
-  - @pnpm/pnpr.client@1.3.10
-  - @pnpm/resolving.resolver-base@1101.1.0
-  - @pnpm/store.controller-types@1101.1.0
-  - @pnpm/store.index@1100.2.3
-  - @pnpm/types@1101.9.0
-  - @pnpm/workspace.project-manifest-reader@1100.0.23
@@ -1,82 +0,0 @@
-## 1101.1.0
-
-### Minor Changes
-
- **Security fix.** Affects projects using `namedRegistries` on pnpm 11.1.0–11.19.x. It is **semi-breaking** for those projects — see "If you use named registries" below.
-
-  The lockfile recorded no marker for which registry a package came from. Packages were keyed by `name@version` alone, and entry lookup went through `refToRelative(ref, name)`, so a dependency you declared against one registry could be satisfied by an entry that was actually resolved from another. When two registries served the same name and version, both collapsed onto a single `packages:` entry and whichever resolved first decided the tarball every consumer got.
-
-  That is a package-substitution risk: a package you expect from your private registry could be installed from a different registry that publishes the same name and version, and the lockfile recorded nothing that would let you tell.
-
-  Packages resolved from a named registry are now recorded under registry-qualified keys (`<name>@<registryName>:<version>`, e.g. `foo@work:1.0.0`), so each registry gets its own entry and the lockfile pins which one a dependency came from.
-
-  The lockfile format version is unchanged. Registry-qualified keys appear only for packages resolved from a named registry, so a project that does not use `namedRegistries` sees no difference, and older pnpm versions keep reading the file.
-
-  ### If you use named registries
-
-  Your next non-frozen install re-keys those entries, which shows up as a lockfile diff. Commit it — that diff is the fix being applied. Review it: an entry that moves to a registry you did not expect is worth investigating.
-
-  Everyone working on the project should be on this version or newer before you do. An older pnpm reads the re-keyed lockfile fine — frozen installs are unaffected — but it does not produce registry-qualified keys itself, so any install that updates the lockfile writes those entries back to the old shape, and the next install on a current pnpm re-qualifies them. The result is a lockfile that flips back and forth, and while it is in the old shape the project is exposed again. Because the lockfile format version is deliberately unchanged, pnpm cannot detect this and warn you about it.
-
-  There is no setting to keep the old behavior: the old shape is the vulnerability.
-
-  Tarball URLs that follow the standard registry layout are no longer written to the lockfile for named-registry packages; they are recomputed from the `namedRegistries` setting on demand.
-
-  To use named registries, map your aliases in `pnpm-workspace.yaml`:
-
-  ```yaml
-  namedRegistries:
-    work: https://npm.enterprise.example.com/
-  ```
-
-  ### New built-in `npmjs:` alias
-
-  `npmjs:` now resolves to `https://registry.npmjs.org/` with no configuration, alongside the existing `gh:` alias for GitHub Packages. It pins a dependency to the public registry even when `registry` points elsewhere, such as an internal proxy:
-
-  ```json
-  { "dependencies": { "left-pad": "npmjs:^1.3.0" } }
-  ```
-
-  `npm:` cannot do this — it is the alias protocol (`npm:<name>@<range>`) and resolves through whatever `registry` points at.
-
-  **If you mirror or proxy npmjs, point the alias at your mirror:**
-
-  ```yaml
-  namedRegistries:
-    npmjs: https://npm.internal.example.com/
-  ```
-
-  Built-in registry URLs are also the prefixes a lockfile's recorded tarball URL is matched against when pnpm verifies a package. Without the override, an entry whose tarball URL is on `registry.npmjs.org` is verified against the public registry rather than your mirror. This only affects lockfiles that record such URLs — a canonical URL for your configured registry is omitted from the lockfile and unaffected — and only when a tarball-URL, `minimumReleaseAge`, or `trustPolicy` check runs. Overriding the alias is the same escape hatch GHES users already have for `gh`.
-
-  Every alias the lockfile references must stay in `namedRegistries`: reading an entry whose alias is gone fails with `ERR_PNPM_MISSING_NAMED_REGISTRY` rather than silently falling back to the default registry, since that would fetch a different package. Renaming an alias re-resolves the packages that used it.
-
-  Named registry aliases that shadow a reserved dependency specifier prefix (`file`, `link`, `workspace`, `runtime`, `npm`, `jsr`, ...) are now rejected with `ERR_PNPM_RESERVED_NAMED_REGISTRY_NAME` instead of being silently shadowed by the corresponding resolver.
-
-  `pnpm licenses` and `pnpm sbom` now keep the two artifacts apart as well: license records carry the registry alias, and SBOM components carry the purl `repository_url` qualifier.
-
-### Patch Changes
-
- Fixed the order in which pnpm matches a lockfile's recorded tarball URL against known registry URLs. Two registry URLs of equal length were previously ordered arbitrarily, so which one a tarball URL matched could differ between runs.
-
- Updated dependencies:
-  - @pnpm/config.normalize-registries@1100.1.0
-  - @pnpm/config.version-policy@1100.1.12
-  - @pnpm/constants@1101.0.0
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/deps.graph-hasher@1100.2.15
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/fetching.pick-fetcher@1100.1.6
-  - @pnpm/fs.symlink-dependency@1100.0.17
-  - @pnpm/hooks.types@1100.2.6
-  - @pnpm/lockfile.preferred-versions@1100.0.28
-  - @pnpm/lockfile.pruner@1100.0.19
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/lockfile.utils@1101.0.0
-  - @pnpm/patching.config@1100.0.15
-  - @pnpm/pkg-manifest.reader@1100.0.15
-  - @pnpm/pkg-manifest.utils@1100.3.1
-  - @pnpm/resolving.npm-resolver@1103.1.0
-  - @pnpm/resolving.resolver-base@1101.1.0
-  - @pnpm/store.controller-types@1101.1.0
-  - @pnpm/types@1101.9.0
@@ -1,86 +0,0 @@
-## 1102.3.0
-
-### Minor Changes
-
- **Security fix.** Affects projects using `namedRegistries` on pnpm 11.1.0–11.19.x. It is **semi-breaking** for those projects — see "If you use named registries" below.
-
-  The lockfile recorded no marker for which registry a package came from. Packages were keyed by `name@version` alone, and entry lookup went through `refToRelative(ref, name)`, so a dependency you declared against one registry could be satisfied by an entry that was actually resolved from another. When two registries served the same name and version, both collapsed onto a single `packages:` entry and whichever resolved first decided the tarball every consumer got.
-
-  That is a package-substitution risk: a package you expect from your private registry could be installed from a different registry that publishes the same name and version, and the lockfile recorded nothing that would let you tell.
-
-  Packages resolved from a named registry are now recorded under registry-qualified keys (`<name>@<registryName>:<version>`, e.g. `foo@work:1.0.0`), so each registry gets its own entry and the lockfile pins which one a dependency came from.
-
-  The lockfile format version is unchanged. Registry-qualified keys appear only for packages resolved from a named registry, so a project that does not use `namedRegistries` sees no difference, and older pnpm versions keep reading the file.
-
-  ### If you use named registries
-
-  Your next non-frozen install re-keys those entries, which shows up as a lockfile diff. Commit it — that diff is the fix being applied. Review it: an entry that moves to a registry you did not expect is worth investigating.
-
-  Everyone working on the project should be on this version or newer before you do. An older pnpm reads the re-keyed lockfile fine — frozen installs are unaffected — but it does not produce registry-qualified keys itself, so any install that updates the lockfile writes those entries back to the old shape, and the next install on a current pnpm re-qualifies them. The result is a lockfile that flips back and forth, and while it is in the old shape the project is exposed again. Because the lockfile format version is deliberately unchanged, pnpm cannot detect this and warn you about it.
-
-  There is no setting to keep the old behavior: the old shape is the vulnerability.
-
-  Tarball URLs that follow the standard registry layout are no longer written to the lockfile for named-registry packages; they are recomputed from the `namedRegistries` setting on demand.
-
-  To use named registries, map your aliases in `pnpm-workspace.yaml`:
-
-  ```yaml
-  namedRegistries:
-    work: https://npm.enterprise.example.com/
-  ```
-
-  ### New built-in `npmjs:` alias
-
-  `npmjs:` now resolves to `https://registry.npmjs.org/` with no configuration, alongside the existing `gh:` alias for GitHub Packages. It pins a dependency to the public registry even when `registry` points elsewhere, such as an internal proxy:
-
-  ```json
-  { "dependencies": { "left-pad": "npmjs:^1.3.0" } }
-  ```
-
-  `npm:` cannot do this — it is the alias protocol (`npm:<name>@<range>`) and resolves through whatever `registry` points at.
-
-  **If you mirror or proxy npmjs, point the alias at your mirror:**
-
-  ```yaml
-  namedRegistries:
-    npmjs: https://npm.internal.example.com/
-  ```
-
-  Built-in registry URLs are also the prefixes a lockfile's recorded tarball URL is matched against when pnpm verifies a package. Without the override, an entry whose tarball URL is on `registry.npmjs.org` is verified against the public registry rather than your mirror. This only affects lockfiles that record such URLs — a canonical URL for your configured registry is omitted from the lockfile and unaffected — and only when a tarball-URL, `minimumReleaseAge`, or `trustPolicy` check runs. Overriding the alias is the same escape hatch GHES users already have for `gh`.
-
-  Every alias the lockfile references must stay in `namedRegistries`: reading an entry whose alias is gone fails with `ERR_PNPM_MISSING_NAMED_REGISTRY` rather than silently falling back to the default registry, since that would fetch a different package. Renaming an alias re-resolves the packages that used it.
-
-  Named registry aliases that shadow a reserved dependency specifier prefix (`file`, `link`, `workspace`, `runtime`, `npm`, `jsr`, ...) are now rejected with `ERR_PNPM_RESERVED_NAMED_REGISTRY_NAME` instead of being silently shadowed by the corresponding resolver.
-
-  `pnpm licenses` and `pnpm sbom` now keep the two artifacts apart as well: license records carry the registry alias, and SBOM components carry the purl `repository_url` qualifier.
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/bins.linker@1100.0.25
-  - @pnpm/building.during-install@1102.0.14
-  - @pnpm/building.policy@1100.0.18
-  - @pnpm/config.package-is-installable@1100.1.2
-  - @pnpm/constants@1101.0.0
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/deps.graph-builder@1100.2.0
-  - @pnpm/deps.graph-hasher@1100.2.15
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/exec.lifecycle@1100.1.11
-  - @pnpm/fs.symlink-dependency@1100.0.17
-  - @pnpm/installing.linking.direct-dep-linker@1100.0.17
-  - @pnpm/installing.linking.hoist@1100.0.25
-  - @pnpm/installing.linking.modules-cleaner@1100.1.18
-  - @pnpm/installing.linking.real-hoist@1100.1.12
-  - @pnpm/installing.modules-yaml@1100.0.15
-  - @pnpm/installing.package-requester@1102.1.9
-  - @pnpm/lockfile.filtering@1100.2.2
-  - @pnpm/lockfile.fs@1100.2.0
-  - @pnpm/lockfile.to-pnp@1100.1.12
-  - @pnpm/lockfile.utils@1101.0.0
-  - @pnpm/patching.config@1100.0.15
-  - @pnpm/pkg-manifest.reader@1100.0.15
-  - @pnpm/store.controller-types@1101.1.0
-  - @pnpm/types@1101.9.0
-  - @pnpm/workspace.project-manifest-reader@1100.0.23
@@ -1,28 +0,0 @@
-## 1102.0.15
-
-### Patch Changes
-
- The env lockfile no longer pins `@pnpm/exe` alongside `pnpm` when the wanted pnpm version is 12 or newer. From v12 the unscoped `pnpm` package is itself the native executable, so `@pnpm/exe` is not published for it and resolving it would fail. The engine identity check now verifies the native binary through whichever package ships it.
-
- Updated dependencies:
-  - @pnpm/config.package-is-installable@1100.1.2
-  - @pnpm/config.pick-registry-for-package@1100.1.0
-  - @pnpm/config.writer@1100.0.21
-  - @pnpm/constants@1101.0.0
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/deps.graph-hasher@1100.2.15
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/fs.symlink-dependency@1100.0.17
-  - @pnpm/installing.deps-resolver@1101.1.0
-  - @pnpm/lockfile.fs@1100.2.0
-  - @pnpm/lockfile.pruner@1100.0.19
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/lockfile.utils@1101.0.0
-  - @pnpm/network.auth-header@1101.1.9
-  - @pnpm/network.fetch@1100.1.11
-  - @pnpm/pkg-manifest.reader@1100.0.15
-  - @pnpm/resolving.npm-resolver@1103.1.0
-  - @pnpm/store.controller@1102.0.11
-  - @pnpm/store.controller-types@1101.1.0
-  - @pnpm/types@1101.9.0
@@ -1,7 +0,0 @@
-## 1100.0.17
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/fs.symlink-dependency@1100.0.17
@@ -1,9 +0,0 @@
-## 1100.0.25
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/bins.linker@1100.0.25
-  - @pnpm/constants@1101.0.0
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/types@1101.9.0
@@ -1,13 +0,0 @@
-## 1100.1.18
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/bins.remover@1100.0.19
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/lockfile.filtering@1100.2.2
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/lockfile.utils@1101.0.0
-  - @pnpm/store.controller-types@1101.1.0
-  - @pnpm/types@1101.9.0
@@ -1,8 +0,0 @@
-## 1100.1.12
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/lockfile.utils@1101.0.0
@@ -1,6 +0,0 @@
-## 1100.0.15
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/types@1101.9.0
@@ -1,17 +0,0 @@
-## 1102.1.9
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/config.package-is-installable@1100.1.2
-  - @pnpm/core-loggers@1100.3.2
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/fetching.fetcher-base@1100.2.7
-  - @pnpm/fetching.pick-fetcher@1100.1.6
-  - @pnpm/hooks.types@1100.2.6
-  - @pnpm/resolving.resolver-base@1101.1.0
-  - @pnpm/store.cafs@1100.1.18
-  - @pnpm/store.controller-types@1101.1.0
-  - @pnpm/store.index@1100.2.3
-  - @pnpm/types@1101.9.0
@@ -1,9 +0,0 @@
-## 1100.0.27
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/config.normalize-registries@1100.1.0
-  - @pnpm/installing.modules-yaml@1100.0.15
-  - @pnpm/lockfile.fs@1100.2.0
-  - @pnpm/types@1101.9.0
@@ -1,8 +0,0 @@
-## 1100.0.19
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/types@1101.9.0
@@ -1,13 +0,0 @@
-## 1100.2.2
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/config.package-is-installable@1100.1.2
-  - @pnpm/constants@1101.0.0
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/lockfile.utils@1101.0.0
-  - @pnpm/lockfile.walker@1100.0.19
-  - @pnpm/types@1101.9.0
@@ -1,66 +0,0 @@
-## 1100.2.0
-
-### Minor Changes
-
- **Security fix.** Affects projects using `namedRegistries` on pnpm 11.1.0–11.19.x. It is **semi-breaking** for those projects — see "If you use named registries" below.
-
-  The lockfile recorded no marker for which registry a package came from. Packages were keyed by `name@version` alone, and entry lookup went through `refToRelative(ref, name)`, so a dependency you declared against one registry could be satisfied by an entry that was actually resolved from another. When two registries served the same name and version, both collapsed onto a single `packages:` entry and whichever resolved first decided the tarball every consumer got.
-
-  That is a package-substitution risk: a package you expect from your private registry could be installed from a different registry that publishes the same name and version, and the lockfile recorded nothing that would let you tell.
-
-  Packages resolved from a named registry are now recorded under registry-qualified keys (`<name>@<registryName>:<version>`, e.g. `foo@work:1.0.0`), so each registry gets its own entry and the lockfile pins which one a dependency came from.
-
-  The lockfile format version is unchanged. Registry-qualified keys appear only for packages resolved from a named registry, so a project that does not use `namedRegistries` sees no difference, and older pnpm versions keep reading the file.
-
-  ### If you use named registries
-
-  Your next non-frozen install re-keys those entries, which shows up as a lockfile diff. Commit it — that diff is the fix being applied. Review it: an entry that moves to a registry you did not expect is worth investigating.
-
-  Everyone working on the project should be on this version or newer before you do. An older pnpm reads the re-keyed lockfile fine — frozen installs are unaffected — but it does not produce registry-qualified keys itself, so any install that updates the lockfile writes those entries back to the old shape, and the next install on a current pnpm re-qualifies them. The result is a lockfile that flips back and forth, and while it is in the old shape the project is exposed again. Because the lockfile format version is deliberately unchanged, pnpm cannot detect this and warn you about it.
-
-  There is no setting to keep the old behavior: the old shape is the vulnerability.
-
-  Tarball URLs that follow the standard registry layout are no longer written to the lockfile for named-registry packages; they are recomputed from the `namedRegistries` setting on demand.
-
-  To use named registries, map your aliases in `pnpm-workspace.yaml`:
-
-  ```yaml
-  namedRegistries:
-    work: https://npm.enterprise.example.com/
-  ```
-
-  ### New built-in `npmjs:` alias
-
-  `npmjs:` now resolves to `https://registry.npmjs.org/` with no configuration, alongside the existing `gh:` alias for GitHub Packages. It pins a dependency to the public registry even when `registry` points elsewhere, such as an internal proxy:
-
-  ```json
-  { "dependencies": { "left-pad": "npmjs:^1.3.0" } }
-  ```
-
-  `npm:` cannot do this — it is the alias protocol (`npm:<name>@<range>`) and resolves through whatever `registry` points at.
-
-  **If you mirror or proxy npmjs, point the alias at your mirror:**
-
-  ```yaml
-  namedRegistries:
-    npmjs: https://npm.internal.example.com/
-  ```
-
-  Built-in registry URLs are also the prefixes a lockfile's recorded tarball URL is matched against when pnpm verifies a package. Without the override, an entry whose tarball URL is on `registry.npmjs.org` is verified against the public registry rather than your mirror. This only affects lockfiles that record such URLs — a canonical URL for your configured registry is omitted from the lockfile and unaffected — and only when a tarball-URL, `minimumReleaseAge`, or `trustPolicy` check runs. Overriding the alias is the same escape hatch GHES users already have for `gh`.
-
-  Every alias the lockfile references must stay in `namedRegistries`: reading an entry whose alias is gone fails with `ERR_PNPM_MISSING_NAMED_REGISTRY` rather than silently falling back to the default registry, since that would fetch a different package. Renaming an alias re-resolves the packages that used it.
-
-  Named registry aliases that shadow a reserved dependency specifier prefix (`file`, `link`, `workspace`, `runtime`, `npm`, `jsr`, ...) are now rejected with `ERR_PNPM_RESERVED_NAMED_REGISTRY_NAME` instead of being silently shadowed by the corresponding resolver.
-
-  `pnpm licenses` and `pnpm sbom` now keep the two artifacts apart as well: license records carry the registry alias, and SBOM components carry the purl `repository_url` qualifier.
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/constants@1101.0.0
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/lockfile.merger@1100.0.19
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/lockfile.utils@1101.0.0
-  - @pnpm/types@1101.9.0
@@ -1,12 +0,0 @@
-## 1100.0.33
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/error@1100.1.1
-  - @pnpm/lockfile.fs@1100.2.0
-  - @pnpm/lockfile.pruner@1100.0.19
-  - @pnpm/releasing.exportable-manifest@1100.2.2
-  - @pnpm/types@1101.9.0
-  - @pnpm/workspace.project-manifest-reader@1100.0.23
-  - @pnpm/workspace.root-finder@1100.0.5
@@ -1,7 +0,0 @@
-## 1100.0.19
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/types@1101.9.0
@@ -1,9 +0,0 @@
-## 1100.0.28
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/lockfile.utils@1101.0.0
-  - @pnpm/pkg-manifest.utils@1100.3.1
-  - @pnpm/resolving.resolver-base@1101.1.0
-  - @pnpm/types@1101.9.0
@@ -1,9 +0,0 @@
-## 1100.0.19
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/constants@1101.0.0
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/types@1101.9.0
@@ -1,8 +0,0 @@
-## 1100.1.10
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/config.parse-overrides@1100.1.2
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/lockfile.verification@1100.0.31
@@ -1,10 +0,0 @@
-## 1100.1.12
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/fs.symlink-dependency@1100.0.17
-  - @pnpm/lockfile.fs@1100.2.0
-  - @pnpm/lockfile.utils@1101.0.0
-  - @pnpm/types@1101.9.0
@@ -1,7 +0,0 @@
-## 1100.0.19
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/resolving.resolver-base@1101.1.0
-  - @pnpm/types@1101.9.0
@@ -1,69 +0,0 @@
-## 1101.0.0
-
-### Major Changes
-
- **Security fix.** Affects projects using `namedRegistries` on pnpm 11.1.0–11.19.x. It is **semi-breaking** for those projects — see "If you use named registries" below.
-
-  The lockfile recorded no marker for which registry a package came from. Packages were keyed by `name@version` alone, and entry lookup went through `refToRelative(ref, name)`, so a dependency you declared against one registry could be satisfied by an entry that was actually resolved from another. When two registries served the same name and version, both collapsed onto a single `packages:` entry and whichever resolved first decided the tarball every consumer got.
-
-  That is a package-substitution risk: a package you expect from your private registry could be installed from a different registry that publishes the same name and version, and the lockfile recorded nothing that would let you tell.
-
-  Packages resolved from a named registry are now recorded under registry-qualified keys (`<name>@<registryName>:<version>`, e.g. `foo@work:1.0.0`), so each registry gets its own entry and the lockfile pins which one a dependency came from.
-
-  The lockfile format version is unchanged. Registry-qualified keys appear only for packages resolved from a named registry, so a project that does not use `namedRegistries` sees no difference, and older pnpm versions keep reading the file.
-
-  ### If you use named registries
-
-  Your next non-frozen install re-keys those entries, which shows up as a lockfile diff. Commit it — that diff is the fix being applied. Review it: an entry that moves to a registry you did not expect is worth investigating.
-
-  Everyone working on the project should be on this version or newer before you do. An older pnpm reads the re-keyed lockfile fine — frozen installs are unaffected — but it does not produce registry-qualified keys itself, so any install that updates the lockfile writes those entries back to the old shape, and the next install on a current pnpm re-qualifies them. The result is a lockfile that flips back and forth, and while it is in the old shape the project is exposed again. Because the lockfile format version is deliberately unchanged, pnpm cannot detect this and warn you about it.
-
-  There is no setting to keep the old behavior: the old shape is the vulnerability.
-
-  Tarball URLs that follow the standard registry layout are no longer written to the lockfile for named-registry packages; they are recomputed from the `namedRegistries` setting on demand.
-
-  To use named registries, map your aliases in `pnpm-workspace.yaml`:
-
-  ```yaml
-  namedRegistries:
-    work: https://npm.enterprise.example.com/
-  ```
-
-  ### New built-in `npmjs:` alias
-
-  `npmjs:` now resolves to `https://registry.npmjs.org/` with no configuration, alongside the existing `gh:` alias for GitHub Packages. It pins a dependency to the public registry even when `registry` points elsewhere, such as an internal proxy:
-
-  ```json
-  { "dependencies": { "left-pad": "npmjs:^1.3.0" } }
-  ```
-
-  `npm:` cannot do this — it is the alias protocol (`npm:<name>@<range>`) and resolves through whatever `registry` points at.
-
-  **If you mirror or proxy npmjs, point the alias at your mirror:**
-
-  ```yaml
-  namedRegistries:
-    npmjs: https://npm.internal.example.com/
-  ```
-
-  Built-in registry URLs are also the prefixes a lockfile's recorded tarball URL is matched against when pnpm verifies a package. Without the override, an entry whose tarball URL is on `registry.npmjs.org` is verified against the public registry rather than your mirror. This only affects lockfiles that record such URLs — a canonical URL for your configured registry is omitted from the lockfile and unaffected — and only when a tarball-URL, `minimumReleaseAge`, or `trustPolicy` check runs. Overriding the alias is the same escape hatch GHES users already have for `gh`.
-
-  Every alias the lockfile references must stay in `namedRegistries`: reading an entry whose alias is gone fails with `ERR_PNPM_MISSING_NAMED_REGISTRY` rather than silently falling back to the default registry, since that would fetch a different package. Renaming an alias re-resolves the packages that used it.
-
-  Named registry aliases that shadow a reserved dependency specifier prefix (`file`, `link`, `workspace`, `runtime`, `npm`, `jsr`, ...) are now rejected with `ERR_PNPM_RESERVED_NAMED_REGISTRY_NAME` instead of being silently shadowed by the corresponding resolver.
-
-  `pnpm licenses` and `pnpm sbom` now keep the two artifacts apart as well: license records carry the registry alias, and SBOM components carry the purl `repository_url` qualifier.
-
-### Patch Changes
-
- Fixed the order in which pnpm matches a lockfile's recorded tarball URL against known registry URLs. Two registry URLs of equal length were previously ordered arbitrarily, so which one a tarball URL matched could differ between runs.
-
- Updated dependencies:
-  - @pnpm/config.normalize-registries@1100.1.0
-  - @pnpm/constants@1101.0.0
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/error@1100.1.1
-  - @pnpm/hooks.types@1100.2.6
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/resolving.resolver-base@1101.1.0
-  - @pnpm/types@1101.9.0
@@ -1,12 +0,0 @@
-## 1100.0.31
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/installing.context@1100.1.0
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/lockfile.utils@1101.0.0
-  - @pnpm/pkg-manifest.reader@1100.0.15
-  - @pnpm/resolving.resolver-base@1101.1.0
-  - @pnpm/types@1101.9.0
@@ -1,8 +0,0 @@
-## 1100.0.19
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/lockfile.types@1100.0.19
-  - @pnpm/types@1101.9.0
@@ -1,13 +0,0 @@
-## 1100.0.36
-
-### Patch Changes
-
- Updated dependencies:
-  - @pnpm/config.reader@1101.16.0
-  - @pnpm/deps.path@1100.1.0
-  - @pnpm/lockfile.fs@1100.2.0
-  - @pnpm/lockfile.utils@1101.0.0
-  - @pnpm/store.cafs@1100.1.18
-  - @pnpm/store.index@1100.2.3
-  - @pnpm/store.path@1100.0.4
-  - @pnpm/types@1101.9.0