@pnpm/resolving.resolver-base 1100.5.1 → 1100.5.3

package/CHANGELOG.md

@@ -0,0 +1,772 @@
+# @pnpm/resolver-base
+
+## 1100.5.3
+
+### Patch Changes
+
+- Updated dependencies:
+  - @pnpm/types@1101.5.0
+
+## 1100.5.2
+
+### Patch Changes
+
+- Updated dependencies:
+  - @pnpm/types@1101.4.0
+
+## 1100.5.1
+
+### Patch Changes
+
+- dcabb78: Fixed `pnpm up <pkg>` producing a different result than a fresh install of the same manifests would. The resolver now distinguishes `updateRequested` (true only for packages that match the user's update target) from the broader `update` flag, and for the targeted package ignores only its own lockfile-derived preferred-version pins — so the target re-resolves exactly as if its lockfile entries were deleted and `pnpm install` ran. Preferred versions a fresh install applies (manifest pins, versions propagated down the dependency chain, and the vulnerability-avoidance penalties of `pnpm audit --fix`) stay in effect, so an update never installs duplicate versions that a reinstall from scratch would not reproduce. When a preferred version holds the update target below the newest version its range admits, pnpm now prints a warning explaining that reaching the newer version everywhere requires an override.
+
+## 1100.5.0
+
+### Minor Changes
+
+- bae694f: Some registries generate tarballs on-demand and cannot provide an integrity checksum in their package metadata. In that case pnpm now computes the integrity from the downloaded tarball and stores it in the lockfile, so the entry is verifiable on subsequent installs instead of being written without an integrity (which would fail the next install). This also applies to `--lockfile-only`: the tarball is downloaded so its integrity can be computed. A lockfile entry that is still missing its integrity is rejected as a `ERR_PNPM_MISSING_TARBALL_INTEGRITY` lockfile verification violation (the install fails closed) rather than being silently re-fetched.
+
+## 1100.4.2
+
+### Patch Changes
+
+- Updated dependencies [681b593]
+  - @pnpm/types@1101.3.2
+
+## 1100.4.1
+
+### Patch Changes
+
+- Updated dependencies [bf1b731]
+  - @pnpm/types@1101.3.1
+
+## 1100.4.0
+
+### Minor Changes
+
+- 6d17b66: The lockfile verifier now checks that a registry entry pinning an explicit `tarball` URL points at the artifact the registry's own metadata lists for that `name@version`. Previously a tampered lockfile could pair a trusted `name@version` with an attacker-chosen tarball URL (and a matching integrity for those bytes), so the install fetched the attacker's bytes. A mismatch — or any entry that can't be confirmed against the registry — is rejected with `ERR_PNPM_TARBALL_URL_MISMATCH`. Non-registry resolutions (`file:`, git-hosted, etc.) and registry entries without an explicit tarball URL (the URL is reconstructed from name+version+registry, so it is inherently bound) are unaffected; non-standard registry tarball URLs (npm Enterprise, GitHub Packages) still pass because they match the metadata.
+
+  This binding is unconditional — it runs regardless of `minimumReleaseAge`/`trustPolicy` and is not narrowed by their exclude lists, since it guards integrity rather than maturity/trust. It is **fail-closed**: an entry passes only when the registry metadata affirmatively lists the version with a matching tarball URL. If the metadata can't be fetched, doesn't list the version, or omits `dist.tarball`, the entry is rejected. As a result, an install that re-verifies a lockfile (any install whose lockfile content changed since the last verified run, where the verification cache no longer applies) now requires the configured registry to be reachable. `trustLockfile` is the opt-out for environments that treat the on-disk lockfile as already trusted.
+
+  The `minimumReleaseAge`/`trustPolicy` verification also no longer applies to URL-keyed tarball dependencies (e.g. `https:` tarballs) that carry a semver `version` copied from their manifest — those are deliberate non-registry dependencies.
+
+### Patch Changes
+
+- Updated dependencies [a017bf3]
+  - @pnpm/types@1101.3.0
+
+## 1100.3.1
+
+### Patch Changes
+
+- Updated dependencies [35d2355]
+  - @pnpm/types@1101.2.0
+
+## 1100.3.0
+
+### Minor Changes
+
+- 1627943: `pnpm outdated` and `pnpm update --interactive` now report Node.js, Deno, and Bun runtimes installed as project dependencies (`runtime:` specifiers). Previously these were silently skipped because the npm specifier parser did not understand the `runtime:` protocol, so runtime versions never appeared in the outdated table or the interactive update picker.
+
+  Internally, the outdated check is now resolver-driven: `@pnpm/resolving.resolver-base` defines a `ResolveLatestFunction` shape (with `LatestQuery` input — `{ wantedDependency, compatible? }` — and `LatestInfo` result — `{ latestManifest? }`), and every protocol resolver (npm, jsr, named-registry, git, tarball, local, node/bun/deno runtimes) exports its own `resolveLatest*` function alongside its `resolve*`. `@pnpm/resolving.default-resolver` composes them into a single dispatcher, exposed through `@pnpm/installing.client` as `createResolver(...).resolveLatest`.
+
+  Each resolver decides whether it owns the dep and what "latest" means for its protocol; the outdated command derives `current` / `wanted` display values from the lockfile snapshot (`pkgSnapshot.version` for semver protocols, raw ref for URL-shaped ones) and uses raw ref equality for the "lockfile changed" check, so protocol knowledge stays inside each resolver instead of the command.
+
+### Patch Changes
+
+- Updated dependencies [64afc92]
+  - @pnpm/types@1101.1.1
+
+## 1100.2.0
+
+### Minor Changes
+
+- 4195766: Tightened the `minimumReleaseAge` story so the bypass becomes explicit on disk instead of silent, and removed the discover-by-loop dance for strict-mode users:
+
+  1. Fresh resolutions in loose mode (`minimumReleaseAgeStrict: false`) that fall back to a version newer than the cutoff auto-collect the picked `name@version` into the workspace manifest's `minimumReleaseAgeExclude`. A single info message lists the additions; entries already on the list are left alone.
+  2. The post-resolution lockfile verifier introduced in #11583 now runs in loose mode too — every accepted-immature pin must be on `minimumReleaseAgeExclude`, just like strict mode requires. A lockfile produced under a weaker (or absent) policy that still has immature entries is rejected the same way strict mode would reject it.
+  3. **Strict mode (interactive)** no longer aborts on the first immature pick. The resolver gathers every immature direct _and_ transitive in one pass; before peer-dependency resolution runs, pnpm prompts the user with the full list and asks whether to add them all to `minimumReleaseAgeExclude` and proceed. Approve → install continues and the workspace manifest is written at the end. Decline → resolution aborts before the lockfile or package.json is touched (tarballs already in the store stay, since the store is idempotent). This closes the [#10488](https://github.com/pnpm/pnpm/issues/10488) loop where security bumps to packages with platform-specific transitives (e.g. `next` + the `@next/swc-*` shims) made users re-run `pnpm add` once per transitive.
+  4. **Strict mode (non-interactive / CI)** now aborts with the full immature set in the error message instead of the first pick. The resolver always collects every immature direct + transitive; the install command then throws `ERR_PNPM_NO_MATURE_MATCHING_VERSION` listing each entry's `name@version` and publish time. Deterministic CI behavior is preserved (same exit code, same error code), but the error pinpoints every offending entry instead of forcing the discover-by-loop dance. The expected workflow is interactive approval locally → the lockfile + workspace manifest get committed → CI runs cleanly against the populated exclude list.
+
+  5. **The lockfile verifier now also covers `trustPolicy: 'no-downgrade'`.** The same post-resolution gate that re-checks `minimumReleaseAge` on lockfile entries now re-runs `failIfTrustDowngraded` for every npm-registry entry whose name isn't on `trustPolicyExclude`. The two checks share a single full-metadata fetch per package, so the extra coverage doesn't cost an extra round trip when both policies are active. Resolver-time trust checks still run as before — this just closes the gap when an entry bypasses resolution (peek path, `--frozen-lockfile`, restored CI cache).
+
+  Pacquet parity: not ported — pacquet's `minimumReleaseAge` policy is itself only stubbed today (see `pnpm/crates/package-manager/src/version_policy.rs`). The auto-exclude, loose-mode verifier, prompt, and the new trust-policy verifier check will travel with the broader policy port whenever that happens.
+
+- 31538bf: Restructured the `minimumReleaseAge` lockfile revalidation gate around a generic `ResolutionVerifier` interface. Each resolver may now export a sibling verifier factory (today: `createNpmResolutionVerifier`) that re-checks an already-resolved lockfile entry against its policies; the resolver chain returns the verifier list as `resolutionVerifiers` and the install side fans out across it. A `ResolutionVerifier` carries `verify` plus `policy` and `canTrustPastCheck` — the cache contract that lets repeat installs against an unchanged lockfile skip the per-package registry round trip entirely.
+
+  Verification results are memoized in JSON Lines at `<cacheDir>/lockfile-verified.jsonl`: a stat-only fast path matches on lockfile size, mtime, and inode, falling back to a content hash when those drift (typical after a CI checkout). Every active verifier's policy contribution is merged into a single `policy` bag on the record; the gate runs in full whenever the lockfile changes, any verifier rejects the cached policy, or no record exists [#11687](https://github.com/pnpm/pnpm/issues/11687).
+
+## 1100.1.3
+
+### Patch Changes
+
+- Updated dependencies [b61e268]
+  - @pnpm/types@1101.1.0
+
+## 1100.1.2
+
+### Patch Changes
+
+- 27425d7: Pin the integrity of git-hosted tarballs (codeload.github.com, gitlab.com, bitbucket.org) in the lockfile so that subsequent installs detect a tampered or substituted tarball and refuse to install it. Previously the lockfile only stored the tarball URL for git dependencies, so a compromised git host or a man-in-the-middle could serve arbitrary code on later installs without lockfile changes.
+
+  A new `gitHosted: true` field is recorded on git-hosted tarball resolutions in the lockfile, letting every reader/writer route them by a single typed check instead of pattern-matching the tarball URL in each call site. Lockfiles written by older pnpm versions are enriched on load (URL fallback) so the field can be relied on uniformly across the codebase.
+
+## 1100.1.1
+
+### Patch Changes
+
+- 184ce26: Fix the package name in README.md.
+
+## 1100.1.0
+
+### Minor Changes
+
+- 72c1e05: Fix: different platform variants of the same runtime (e.g. `node@runtime:25.9.0` glibc vs. musl) no longer share a single global-virtual-store entry. The virtual store path now incorporates the selected variant's integrity, so installs with different `--os`/`--cpu`/`--libc` end up in separate directories and `pnpm add --libc=musl node@runtime:<v>` reliably fetches the musl binary even when the glibc variant is already cached.
+
+## 1100.0.1
+
+### Patch Changes
+
+- Updated dependencies [ff28085]
+  - @pnpm/types@1101.0.0
+
+## 1006.0.0
+
+### Major Changes
+
+- 491a84f: This package is now pure ESM.
+- 7d2fd48: Node.js v18, 19, 20, and 21 support discontinued.
+
+### Minor Changes
+
+- facdd71: Adding `trustPolicyIgnoreAfter` allows you to ignore trust policy checks for packages published more than a specified time ago[#10352](https://github.com/pnpm/pnpm/issues/10352).
+- 10bc391: Added a new setting: `trustPolicy`.
+- 38b8e35: Support for custom resolvers and fetchers.
+- 9d3f00b: Added support for `trustPolicyExclude` [#10164](https://github.com/pnpm/pnpm/issues/10164).
+
+  You can now list one or more specific packages or versions that pnpm should allow to install, even if those packages don't satisfy the trust policy requirement. For example:
+
+  ```yaml
+  trustPolicy: no-downgrade
+  trustPolicyExclude:
+    - chokidar@4.0.3
+    - webpack@4.47.0 || 5.102.1
+  ```
+
+### Patch Changes
+
+- 9b0a460: Fixed a resolution bug that could cause `pnpm dedupe --check` to fail unexpectedly.
+
+  When adding new dependencies to `package.json`, pnpm generally reuses existing versions in the `pnpm-lock.yaml` if they are satisfied by the version range specifier. There was an edge case where pnpm would instead resolve to a newly released version of a dependency. This is particularly problematic for `pnpm dedupe --check`, since a new version of a dependency published to the NPM registry could cause this check to suddenly fail. For details of this bug, see [#10626](https://github.com/pnpm/pnpm/issues/10626). This bug has been fixed.
+
+  The fix necessitated a behavioral change: In some cases, pnpm was previously able to automatically dedupe a newly used dependency deep in the dependency graph without needing to run `pnpm dedupe`. This behavior was supported by the non-determinism that is now corrected. We believe fixing this non-determinism is more important than preserving an automatic dedupe heuristic that didn't handle all cases. The `pnpm dedupe` command can still be used to clean up dependencies that aren't automatically deduped on `pnpm install`.
+
+- 50fbeca: Added `getNodeBinsForCurrentOS` to `@pnpm/constants` which returns a `Record<string, string>` with paths for `node`, `npm`, and `npx` within the Node.js package. This record is now used as `BinaryResolution.bin` (type widened from `string` to `string | Record<string, string>`) and as `manifest.bin` in the node resolver, so pnpm's bin-linker creates all three shims automatically when installing a Node.js runtime.
+- Updated dependencies [76718b3]
+- Updated dependencies [a8f016c]
+- Updated dependencies [cc1b8e3]
+- Updated dependencies [491a84f]
+- Updated dependencies [7d2fd48]
+- Updated dependencies [efb48dc]
+- Updated dependencies [cb367b9]
+- Updated dependencies [7b1c189]
+- Updated dependencies [8ffb1a7]
+- Updated dependencies [05fb1ae]
+- Updated dependencies [71de2b3]
+- Updated dependencies [10bc391]
+- Updated dependencies [2df8b71]
+- Updated dependencies [15549a9]
+- Updated dependencies [cc7c0d2]
+- Updated dependencies [efb48dc]
+  - @pnpm/types@1001.0.0
+
+## 1005.1.0
+
+### Minor Changes
+
+- 7c1382f: The npm resolver supports `publishedByExclude` now.
+
+### Patch Changes
+
+- Updated dependencies [7c1382f]
+- Updated dependencies [dee39ec]
+  - @pnpm/types@1000.9.0
+
+## 1005.0.1
+
+### Patch Changes
+
+- Updated dependencies [e792927]
+  - @pnpm/types@1000.8.0
+
+## 1005.0.0
+
+### Major Changes
+
+- d1edf73: Rename Resolution to AtomicResolution. Add support for binary resolution.
+- f91922c: Changed how the integrity of the node.js artifact is stored in the lockfile.
+
+### Minor Changes
+
+- 86b33e9: Added support for installing Bun runtime.
+
+## 1004.1.0
+
+### Minor Changes
+
+- 1a07b8f: Added support for resolving and downloading the Node.js runtime specified in the [devEngines](https://github.com/openjs-foundation/package-metadata-interoperability-collab-space/issues/15) field of `package.json`.
+
+  Usage example:
+
+  ```json
+  {
+    "devEngines": {
+      "runtime": {
+        "name": "node",
+        "version": "^24.4.0",
+        "onFail": "download"
+      }
+    }
+  }
+  ```
+
+  When running `pnpm install`, pnpm will resolve Node.js to the latest version that satisfies the specified range and install it as a dependency of the project. As a result, when running scripts, the locally installed Node.js version will be used.
+
+  Unlike the existing options, `useNodeVersion` and `executionEnv.nodeVersion`, this new field supports version ranges, which are locked to exact versions during installation. The resolved version is stored in the pnpm lockfile, along with an integrity checksum for future validation of the Node.js content's validity.
+
+  Related PR: [#9755](https://github.com/pnpm/pnpm/pull/9755).
+
+### Patch Changes
+
+- Updated dependencies [1a07b8f]
+  - @pnpm/types@1000.7.0
+
+## 1004.0.0
+
+### Major Changes
+
+- 2721291: Create different resolver result types which provide more information.
+- 6acf819: Remove the blanket variant from the `Resolution` type, making it stricter and more useful.
+
+## 1003.0.1
+
+### Patch Changes
+
+- Updated dependencies [5ec7255]
+  - @pnpm/types@1000.6.0
+
+## 1003.0.0
+
+### Major Changes
+
+- 8a9f3a4: `pref` renamed to `bareSpecifier`.
+- 5b73df1: Renamed `normalizedPref` to `specifiers`.
+
+### Minor Changes
+
+- 9c3dd03: **Added support for installing JSR packages.** You can now install JSR packages using the following syntax:
+
+  ```
+  pnpm add jsr:<pkg_name>
+  ```
+
+  or with a version range:
+
+  ```
+  pnpm add jsr:<pkg_name>@<range>
+  ```
+
+  For example, running:
+
+  ```
+  pnpm add jsr:@foo/bar
+  ```
+
+  will add the following entry to your `package.json`:
+
+  ```json
+  {
+    "dependencies": {
+      "@foo/bar": "jsr:^0.1.2"
+    }
+  }
+  ```
+
+  When publishing, this entry will be transformed into a format compatible with npm, older versions of Yarn, and previous pnpm versions:
+
+  ```json
+  {
+    "dependencies": {
+      "@foo/bar": "npm:@jsr/foo__bar@^0.1.2"
+    }
+  }
+  ```
+
+  Related issue: [#8941](https://github.com/pnpm/pnpm/issues/8941).
+
+  Note: The `@jsr` scope defaults to <https://npm.jsr.io/> if the `@jsr:registry` setting is not defined.
+
+### Patch Changes
+
+- Updated dependencies [5b73df1]
+  - @pnpm/types@1000.5.0
+
+## 1002.0.0
+
+### Major Changes
+
+- 81f441c: `updateToLatest` replaced with `update` field.
+
+## 1001.0.0
+
+### Major Changes
+
+- 72cff38: The resolving function now takes a `registries` object, so it finds the required registry itself instead of receiving it from package requester.
+
+### Patch Changes
+
+- Updated dependencies [750ae7d]
+  - @pnpm/types@1000.4.0
+
+## 1000.2.1
+
+### Patch Changes
+
+- Updated dependencies [5f7be64]
+- Updated dependencies [5f7be64]
+  - @pnpm/types@1000.3.0
+
+## 1000.2.0
+
+### Minor Changes
+
+- 3d52365: The `@pnpm/npm-resolver` package can now return `workspace` in the `resolvedVia` field of its results. This will be the case if the resolved package was requested through the `workspace:` protocol or if the wanted dependency's name and specifier match a package in the workspace. Previously, the `resolvedVia` field was always set to `local-filesystem` for workspace packages.
+
+## 1000.1.4
+
+### Patch Changes
+
+- Updated dependencies [a5e4965]
+  - @pnpm/types@1000.2.1
+
+## 1000.1.3
+
+### Patch Changes
+
+- Updated dependencies [8fcc221]
+  - @pnpm/types@1000.2.0
+
+## 1000.1.2
+
+### Patch Changes
+
+- Updated dependencies [b562deb]
+  - @pnpm/types@1000.1.1
+
+## 1000.1.1
+
+### Patch Changes
+
+- Updated dependencies [9591a18]
+  - @pnpm/types@1000.1.0
+
+## 1000.1.0
+
+### Minor Changes
+
+- 6483b64: A new setting, `inject-workspace-packages`, has been added to allow hard-linking all local workspace dependencies instead of symlinking them. Previously, this behavior was achievable via the [`dependenciesMeta[].injected`](https://pnpm.io/package_json#dependenciesmetainjected) setting, which remains supported [#8836](https://github.com/pnpm/pnpm/pull/8836).
+
+## 13.0.4
+
+### Patch Changes
+
+- Updated dependencies [d500d9f]
+  - @pnpm/types@12.2.0
+
+## 13.0.3
+
+### Patch Changes
+
+- Updated dependencies [7ee59a1]
+  - @pnpm/types@12.1.0
+
+## 13.0.2
+
+### Patch Changes
+
+- Updated dependencies [cb006df]
+  - @pnpm/types@12.0.0
+
+## 13.0.1
+
+### Patch Changes
+
+- Updated dependencies [0ef168b]
+  - @pnpm/types@11.1.0
+
+## 13.0.0
+
+### Major Changes
+
+- dd00eeb: Renamed dir to rootDir in the Project object.
+
+### Patch Changes
+
+- Updated dependencies [dd00eeb]
+- Updated dependencies
+  - @pnpm/types@11.0.0
+
+## 12.0.2
+
+### Patch Changes
+
+- Updated dependencies [13e55b2]
+  - @pnpm/types@10.1.1
+
+## 12.0.1
+
+### Patch Changes
+
+- Updated dependencies [45f4262]
+  - @pnpm/types@10.1.0
+
+## 12.0.0
+
+### Major Changes
+
+- 43cdd87: Node.js v16 support dropped. Use at least Node.js v18.12.
+
+### Minor Changes
+
+- b13d2dc: It is now possible to install only a subdirectory from a Git repository.
+
+  For example, `pnpm add github:user/repo#path:packages/foo` will add a dependency from the `packages/foo` subdirectory.
+
+  This new parameter may be combined with other supported parameters separated by `&`. For instance, the next command will install the same package from the `dev` branch: `pnpm add github:user/repo#dev&path:packages/bar`.
+
+  Related issue: [#4765](https://github.com/pnpm/pnpm/issues/4765).
+  Related PR: [#7487](https://github.com/pnpm/pnpm/pull/7487).
+
+### Patch Changes
+
+- Updated dependencies [7733f3a]
+- Updated dependencies [43cdd87]
+- Updated dependencies [730929e]
+  - @pnpm/types@10.0.0
+
+## 11.1.0
+
+### Minor Changes
+
+- 31054a63e: Running `pnpm update -r --latest` will no longer downgrade prerelease dependencies [#7436](https://github.com/pnpm/pnpm/issues/7436).
+
+## 11.0.2
+
+### Patch Changes
+
+- Updated dependencies [4d34684f1]
+  - @pnpm/types@9.4.2
+
+## 11.0.1
+
+### Patch Changes
+
+- Updated dependencies
+  - @pnpm/types@9.4.1
+
+## 11.0.0
+
+### Major Changes
+
+- 4c2450208: (Important) Tarball resolutions in `pnpm-lock.yaml` will no longer contain a `registry` field. This field has been unused for a long time. This change should not cause any issues besides backward compatible modifications to the lockfile [#7262](https://github.com/pnpm/pnpm/pull/7262).
+
+## 10.0.4
+
+### Patch Changes
+
+- Updated dependencies [43ce9e4a6]
+  - @pnpm/types@9.4.0
+
+## 10.0.3
+
+### Patch Changes
+
+- Updated dependencies [d774a3196]
+  - @pnpm/types@9.3.0
+
+## 10.0.2
+
+### Patch Changes
+
+- Updated dependencies [aa2ae8fe2]
+  - @pnpm/types@9.2.0
+
+## 10.0.1
+
+### Patch Changes
+
+- Updated dependencies [a9e0b7cbf]
+  - @pnpm/types@9.1.0
+
+## 10.0.0
+
+### Major Changes
+
+- eceaa8b8b: Node.js 14 support dropped.
+
+### Patch Changes
+
+- Updated dependencies [eceaa8b8b]
+  - @pnpm/types@9.0.0
+
+## 9.2.0
+
+### Minor Changes
+
+- 029143cff: Version selectors may have weights optionally.
+
+### Patch Changes
+
+- 029143cff: When resolving dependencies, prefer versions that are already used in the root of the project. This is important to minimize the number of packages that will be nested during hoisting [#6054](https://github.com/pnpm/pnpm/pull/6054).
+
+## 9.1.5
+
+### Patch Changes
+
+- Updated dependencies [b77651d14]
+  - @pnpm/types@8.10.0
+
+## 9.1.4
+
+### Patch Changes
+
+- Updated dependencies [702e847c1]
+  - @pnpm/types@8.9.0
+
+## 9.1.3
+
+### Patch Changes
+
+- Updated dependencies [844e82f3a]
+  - @pnpm/types@8.8.0
+
+## 9.1.2
+
+### Patch Changes
+
+- Updated dependencies [d665f3ff7]
+  - @pnpm/types@8.7.0
+
+## 9.1.1
+
+### Patch Changes
+
+- Updated dependencies [156cc1ef6]
+  - @pnpm/types@8.6.0
+
+## 9.1.0
+
+### Minor Changes
+
+- 23984abd1: Add hook for adding custom fetchers.
+
+## 9.0.6
+
+### Patch Changes
+
+- Updated dependencies [c90798461]
+  - @pnpm/types@8.5.0
+
+## 9.0.5
+
+### Patch Changes
+
+- Updated dependencies [8e5b77ef6]
+  - @pnpm/types@8.4.0
+
+## 9.0.4
+
+### Patch Changes
+
+- Updated dependencies [2a34b21ce]
+  - @pnpm/types@8.3.0
+
+## 9.0.3
+
+### Patch Changes
+
+- Updated dependencies [fb5bbfd7a]
+  - @pnpm/types@8.2.0
+
+## 9.0.2
+
+### Patch Changes
+
+- Updated dependencies [4d39e4a0c]
+  - @pnpm/types@8.1.0
+
+## 9.0.1
+
+### Patch Changes
+
+- Updated dependencies [18ba5e2c0]
+  - @pnpm/types@8.0.1
+
+## 9.0.0
+
+### Major Changes
+
+- 542014839: Node.js 12 is not supported.
+
+### Patch Changes
+
+- Updated dependencies [d504dc380]
+- Updated dependencies [542014839]
+  - @pnpm/types@8.0.0
+
+## 8.1.6
+
+### Patch Changes
+
+- Updated dependencies [b138d048c]
+  - @pnpm/types@7.10.0
+
+## 8.1.5
+
+### Patch Changes
+
+- Updated dependencies [26cd01b88]
+  - @pnpm/types@7.9.0
+
+## 8.1.4
+
+### Patch Changes
+
+- Updated dependencies [b5734a4a7]
+  - @pnpm/types@7.8.0
+
+## 8.1.3
+
+### Patch Changes
+
+- Updated dependencies [6493e0c93]
+  - @pnpm/types@7.7.1
+
+## 8.1.2
+
+### Patch Changes
+
+- Updated dependencies [ba9b2eba1]
+  - @pnpm/types@7.7.0
+
+## 8.1.1
+
+### Patch Changes
+
+- Updated dependencies [302ae4f6f]
+  - @pnpm/types@7.6.0
+
+## 8.1.0
+
+### Minor Changes
+
+- 4ab87844a: New optional property added to `WantedDependency`: `injected`.
+
+### Patch Changes
+
+- Updated dependencies [4ab87844a]
+  - @pnpm/types@7.5.0
+
+## 8.0.4
+
+### Patch Changes
+
+- Updated dependencies [b734b45ea]
+  - @pnpm/types@7.4.0
+
+## 8.0.3
+
+### Patch Changes
+
+- Updated dependencies [8e76690f4]
+  - @pnpm/types@7.3.0
+
+## 8.0.2
+
+### Patch Changes
+
+- Updated dependencies [724c5abd8]
+  - @pnpm/types@7.2.0
+
+## 8.0.1
+
+### Patch Changes
+
+- Updated dependencies [97c64bae4]
+  - @pnpm/types@7.1.0
+
+## 8.0.0
+
+### Major Changes
+
+- 97b986fbc: Node.js 10 support is dropped. At least Node.js 12.17 is required for the package to work.
+
+### Patch Changes
+
+- Updated dependencies [97b986fbc]
+  - @pnpm/types@7.0.0
+
+## 7.1.1
+
+### Patch Changes
+
+- Updated dependencies [9ad8c27bf]
+  - @pnpm/types@6.4.0
+
+## 7.1.0
+
+### Minor Changes
+
+- 8698a7060: New option added: preferWorkspacePackages. When it is `true`, dependencies are linked from the workspace even, when there are newer version available in the registry.
+
+## 7.0.5
+
+### Patch Changes
+
+- Updated dependencies [b5d694e7f]
+  - @pnpm/types@6.3.1
+
+## 7.0.4
+
+### Patch Changes
+
+- Updated dependencies [d54043ee4]
+  - @pnpm/types@6.3.0
+
+## 7.0.3
+
+### Patch Changes
+
+- Updated dependencies [db17f6f7b]
+  - @pnpm/types@6.2.0
+
+## 7.0.2
+
+### Patch Changes
+
+- Updated dependencies [71a8c8ce3]
+  - @pnpm/types@6.1.0
+
+## 7.0.1
+
+### Patch Changes
+
+- Updated dependencies [da091c711]
+  - @pnpm/types@6.0.0
+
+## 7.0.1-alpha.0
+
+### Patch Changes
+
+- Updated dependencies [da091c71]
+  - @pnpm/types@6.0.0-alpha.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pnpm/resolving.resolver-base",
-  "version": "1100.5.1",
+  "version": "1100.5.3",
   "description": "Types for pnpm-compatible resolvers",
   "keywords": [
     "pnpm",
@@ -28,11 +28,11 @@
     "!*.map"
   ],
   "dependencies": {
-    "@pnpm/types": "1101.3.2"
+    "@pnpm/types": "1101.5.0"
   },
   "devDependencies": {
     "@jest/globals": "30.4.1",
-    "@pnpm/resolving.resolver-base": "1100.5.1"
+    "@pnpm/resolving.resolver-base": "1100.5.3"
   },
   "engines": {
     "node": ">=22.13"

package/lib/index.d.ts

@@ -1,296 +0,0 @@
-import type { DependencyManifest, PackageManifest, PackageVersionPolicy, PinnedVersion, PkgResolutionId, ProjectRootDir, SupportedArchitectures, TrustPolicy } from '@pnpm/types';
-export { type PkgResolutionId };
-/**
- * tarball hosted remotely
- */
-export interface TarballResolution {
-    type?: undefined;
-    tarball: string;
-    integrity?: string;
-    path?: string;
-    /**
-     * True for tarballs sourced from a git host (codeload.github.com /
-     * gitlab.com / bitbucket.org). Such tarballs need preparation
-     * (preparePackage / packlist) on extraction, and their cached content
-     * depends on whether build scripts ran, so they're addressed by
-     * gitHostedStoreIndexKey rather than the integrity-based key.
-     */
-    gitHosted?: boolean;
-}
-export interface BinaryResolution {
-    type: 'binary';
-    archive: 'tarball' | 'zip';
-    url: string;
-    integrity: string;
-    bin: string | Record<string, string>;
-    prefix?: string;
-}
-/**
- * directory on a file system
- */
-export interface DirectoryResolution {
-    type: 'directory';
-    directory: string;
-}
-export interface GitResolution {
-    commit: string;
-    repo: string;
-    path?: string;
-    type: 'git';
-}
-export interface CustomResolution {
-    type: `custom:${string}`;
-    [key: string]: unknown;
-}
-export interface PlatformAssetTarget {
-    os: string;
-    cpu: string;
-    libc?: 'musl';
-}
-export interface PlatformAssetResolution {
-    resolution: AtomicResolution;
-    targets: PlatformAssetTarget[];
-}
-export type AtomicResolution = TarballResolution | DirectoryResolution | GitResolution | BinaryResolution | CustomResolution;
-export interface VariationsResolution {
-    type: 'variations';
-    variants: PlatformAssetResolution[];
-}
-export type Resolution = AtomicResolution | VariationsResolution;
-/**
- * A tarball URL is git-hosted when it points at a known git provider's immutable
- * archive endpoint. The result gates integrity exemptions, so the match is
- * limited to provider-specific path shapes whose ref is a full commit SHA.
- */
-export declare function isGitHostedTarballUrl(url: string): boolean;
-export type ResolutionKind = 'localTarball' | 'gitHostedTarball' | 'remoteTarball' | 'directory' | 'git' | 'binary' | 'custom';
-/**
- * Classifies a resolution for fetcher selection. Lockfile-provided flags are
- * treated as hints; integrity exemptions depend on the resolved source shape.
- */
-export declare function classifyResolution(resolution: Resolution): ResolutionKind;
-/**
- * Outcome of asking a `ResolutionVerifier` whether a (name, version,
- * resolution) entry from a lockfile is acceptable under whatever policies
- * the resolver chain has been configured with. Resolvers that don't have
- * an opinion on a given resolution should return `{ ok: true }`.
- */
-export type ResolutionVerification = {
-    ok: true;
-} | {
-    ok: false;
-    code: string;
-    reason: string;
-};
-/**
- * Optional companion to a resolver factory.
- *
- * `verify` inspects the `resolution` shape to decide whether the entry
- * is within its protocol; for entries outside its protocol it should
- * return `{ ok: true }`. The install side fans out across the verifier
- * list rather than asking a combinator to dispatch.
- *
- * `policy` and `canTrustPastCheck` describe the verifier's cache
- * contract. Policies from every active verifier are merged into a
- * single shared bag stored alongside the lockfile hash; the
- * install-side verification cache reads them to decide if a previous
- * run on the same lockfile is still trustworthy under today's policy
- * without re-issuing the registry round-trips that `verify` would.
- * Verifiers that check the same logical policy (e.g. minimumReleaseAge
- * across registries) name it the same and share the cache slot.
- */
-export interface ResolutionVerifier {
-    /**
-     * `ctx.nonSemverVersion` is set when the lockfile entry is keyed by a
-     * non-semver reference (URL tarball, git, etc.) rather than a registry
-     * `name@version`. Verifiers that only police registry entries use it to
-     * skip deliberate non-registry deps, which can still carry a semver
-     * `version` copied from the resolved manifest.
-     */
-    verify: (resolution: Resolution, ctx: {
-        name: string;
-        version: string;
-        nonSemverVersion?: string;
-    }) => Promise<ResolutionVerification>;
-    /**
-     * Snapshot of the policy fields this verifier enforces. Merged with
-     * every other active verifier's `policy` into the cache record. A
-     * field shared across verifiers (same key) should carry the same
-     * value; if it doesn't, the last verifier in the list wins.
-     */
-    policy: Record<string, unknown>;
-    /**
-     * Returns true when the previously cached policy (the merged snapshot
-     * from the last successful run) can be trusted to still satisfy what
-     * this verifier currently demands. Reads whichever fields the
-     * verifier owns; missing or non-conforming values (e.g. an older
-     * record shape) should return false. A loosened policy can trust a
-     * stricter cached run; a tightened policy cannot.
-     */
-    canTrustPastCheck: (cachedPolicy: Record<string, unknown>) => boolean;
-}
-/**
- * A `ResolutionVerifier`'s rejection materialized for one (name,
- * version, resolution) entry. The install side aggregates these across
- * every active verifier on the freshly-resolved tree and either prompts
- * the user, persists them (e.g. into `minimumReleaseAgeExclude`), or
- * aborts. Code is the verifier-defined error code
- * (`MINIMUM_RELEASE_AGE_VIOLATION`, `TRUST_DOWNGRADE`, etc.) — the
- * install command filters by code to decide downstream UX. Lifted here
- * (rather than in deps-installer) so both deps-resolver and
- * deps-installer can share one shape; future resolver packages plug in
- * without needing the deps-installer dependency.
- */
-export interface ResolutionPolicyViolation {
-    name: string;
-    version: string;
-    resolution: Resolution;
-    code: string;
-    reason: string;
-}
-/** Concrete platform selector used when picking a variant from a VariationsResolution. */
-export interface PlatformSelector {
-    os: string;
-    cpu: string;
-    /** Name of the libc family requested. Omit (or leave `null`) for the default (glibc on Linux, n/a elsewhere). */
-    libc?: string | null;
-}
-/**
- * Resolve a {@link PlatformSelector} from the user's supportedArchitectures config
- * and the host's own platform/arch/libc. When `supportedArchitectures.xxx` is set
- * and its first entry is not `"current"`, that entry wins; otherwise the host's
- * value is used. Additional entries beyond the first are ignored — variant
- * selection picks exactly one (os, cpu, libc) triplet per install.
- */
-export declare function resolvePlatformSelector(supportedArchitectures: SupportedArchitectures | undefined, host: {
-    platform: string;
-    arch: string;
-    libc: string | null | undefined;
-}): PlatformSelector;
-/**
- * Pick the variant whose target matches the given selector, or `undefined` if
- * none does. A variant with no `libc` represents the "default" build — glibc on
- * Linux, irrelevant on macOS/Windows. A non-default libc (e.g. `musl`) is a
- * separate, non-interchangeable artifact; an exact libc match is required in
- * that case so the glibc/default variant doesn't silently win (its `target.libc`
- * is nullish).
- */
-export declare function selectPlatformVariant(variants: PlatformAssetResolution[], selector: PlatformSelector): PlatformAssetResolution | undefined;
-export interface ResolveResult {
-    id: PkgResolutionId;
-    latest?: string;
-    publishedAt?: string;
-    manifest?: DependencyManifest;
-    resolution: Resolution;
-    resolvedVia: string;
-    normalizedBareSpecifier?: string;
-    alias?: string;
-    /**
-     * Set when the resolver picked this version despite a policy
-     * violation (e.g. immature relative to `publishedBy`, trust
-     * downgrade detected by `failIfTrustDowngraded`). The resolver
-     * already has the metadata it needs to decide, so reporting inline
-     * here avoids the install layer having to re-scan the tree and
-     * re-fetch the same metadata. The deps-resolver aggregates these
-     * across every resolve call into a single set the install command
-     * can react to.
-     *
-     * `resolution` on the violation is the same `resolution` field
-     * above — supplied for symmetry with `ResolutionPolicyViolation`
-     * entries that flow out of `verifyLockfileResolutions` for
-     * lockfile-only paths.
-     */
-    policyViolation?: ResolutionPolicyViolation;
-}
-export interface WorkspacePackage {
-    rootDir: ProjectRootDir;
-    manifest: DependencyManifest;
-}
-export type WorkspacePackagesByVersion = Map<string, WorkspacePackage>;
-export type WorkspacePackages = Map<string, WorkspacePackagesByVersion>;
-export declare const DIRECT_DEP_SELECTOR_WEIGHT = 1000;
-export declare const EXISTING_VERSION_SELECTOR_WEIGHT = 1000000;
-export type VersionSelectorType = 'version' | 'range' | 'tag';
-export interface VersionSelectors {
-    [selector: string]: VersionSelectorWithWeight | VersionSelectorType;
-}
-export interface VersionSelectorWithWeight {
-    selectorType: VersionSelectorType;
-    weight: number;
-}
-export interface PreferredVersions {
-    [packageName: string]: VersionSelectors;
-}
-export interface ResolveOptions {
-    alwaysTryWorkspacePackages?: boolean;
-    trustPolicy?: TrustPolicy;
-    trustPolicyExclude?: PackageVersionPolicy;
-    trustPolicyIgnoreAfter?: number;
-    defaultTag?: string;
-    pickLowestVersion?: boolean;
-    publishedBy?: Date;
-    publishedByExclude?: PackageVersionPolicy;
-    projectDir: string;
-    lockfileDir: string;
-    preferredVersions: PreferredVersions;
-    preferWorkspacePackages?: boolean;
-    workspacePackages?: WorkspacePackages;
-    update?: false | 'compatible' | 'latest';
-    /**
-     * True only when this specific package matches the user's update target
-     * (e.g. `pnpm up <name>`). Unlike `update`, this is false for unrelated
-     * packages that get re-resolved as a side effect of an update, so it can
-     * be used to bypass preferred-version propagation without forcing
-     * unrelated transitives to jump to their latest versions.
-     */
-    updateRequested?: boolean;
-    updateChecksums?: boolean;
-    injectWorkspacePackages?: boolean;
-    calcSpecifier?: boolean;
-    pinnedVersion?: PinnedVersion;
-    currentPkg?: {
-        id: PkgResolutionId;
-        name?: string;
-        version?: string;
-        resolution: Resolution;
-        publishedAt?: string;
-    };
-}
-export type WantedDependency = {
-    injected?: boolean;
-    prevSpecifier?: string;
-} & ({
-    alias?: string;
-    bareSpecifier: string;
-} | {
-    alias: string;
-    bareSpecifier?: string;
-});
-export type ResolveFunction = (wantedDependency: WantedDependency & {
-    optional?: boolean;
-}, opts: ResolveOptions) => Promise<ResolveResult>;
-/**
- * Input to a resolver's `resolveLatest` function. The resolver decides
- * whether it owns this dep purely from `wantedDependency` (its alias and
- * manifest specifier) — the lockfile-resolved ref is the caller's
- * concern, not the resolver's.
- */
-export interface LatestQuery {
-    wantedDependency: WantedDependency;
-    compatible?: boolean;
-}
-/**
- * Result of a resolver's `resolveLatest` call.
- *
- * - `undefined` means "this resolver does not handle this dep — try
- *   the next one".
- * - An object (even without a `latestManifest`) means "I claim this
- *   dep, but I can't tell you what's latest" (e.g. policy blocked,
- *   network unavailable, no concept of latest for this protocol).
- *   The caller still surfaces a ref-mismatch report if the lockfile
- *   shifted.
- */
-export interface LatestInfo {
-    latestManifest?: PackageManifest;
-}
-export type ResolveLatestFunction = (query: LatestQuery, opts: ResolveOptions) => Promise<LatestInfo | undefined>;