@pnpm/resolving.resolver-base 1100.5.3 → 1100.5.5

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,21 @@
1
1
  # @pnpm/resolver-base
2
2
 
3
+ ## 1100.5.5
4
+
5
+ ### Patch Changes
6
+
7
+ - Updated dependencies:
8
+ - @pnpm/types@1101.7.0
9
+
10
+ ## 1100.5.4
11
+
12
+ ### Patch Changes
13
+
14
+ - Republished every package: the tarballs published by the v11.13.1 through v11.16.0 releases were missing most of their compiled files due to a packing bug [#13164](https://github.com/pnpm/pnpm/issues/13164).
15
+
16
+ - Updated dependencies:
17
+ - @pnpm/types@1101.6.0
18
+
3
19
  ## 1100.5.3
4
20
 
5
21
  ### Patch Changes
package/lib/index.d.ts ADDED
@@ -0,0 +1,296 @@
1
+ import type { DependencyManifest, PackageManifest, PackageVersionPolicy, PinnedVersion, PkgResolutionId, ProjectRootDir, SupportedArchitectures, TrustPolicy } from '@pnpm/types';
2
+ export { type PkgResolutionId };
3
+ /**
4
+ * tarball hosted remotely
5
+ */
6
+ export interface TarballResolution {
7
+ type?: undefined;
8
+ tarball: string;
9
+ integrity?: string;
10
+ path?: string;
11
+ /**
12
+ * True for tarballs sourced from a git host (codeload.github.com /
13
+ * gitlab.com / bitbucket.org). Such tarballs need preparation
14
+ * (preparePackage / packlist) on extraction, and their cached content
15
+ * depends on whether build scripts ran, so they're addressed by
16
+ * gitHostedStoreIndexKey rather than the integrity-based key.
17
+ */
18
+ gitHosted?: boolean;
19
+ }
20
+ export interface BinaryResolution {
21
+ type: 'binary';
22
+ archive: 'tarball' | 'zip';
23
+ url: string;
24
+ integrity: string;
25
+ bin: string | Record<string, string>;
26
+ prefix?: string;
27
+ }
28
+ /**
29
+ * directory on a file system
30
+ */
31
+ export interface DirectoryResolution {
32
+ type: 'directory';
33
+ directory: string;
34
+ }
35
+ export interface GitResolution {
36
+ commit: string;
37
+ repo: string;
38
+ path?: string;
39
+ type: 'git';
40
+ }
41
+ export interface CustomResolution {
42
+ type: `custom:${string}`;
43
+ [key: string]: unknown;
44
+ }
45
+ export interface PlatformAssetTarget {
46
+ os: string;
47
+ cpu: string;
48
+ libc?: 'musl';
49
+ }
50
+ export interface PlatformAssetResolution {
51
+ resolution: AtomicResolution;
52
+ targets: PlatformAssetTarget[];
53
+ }
54
+ export type AtomicResolution = TarballResolution | DirectoryResolution | GitResolution | BinaryResolution | CustomResolution;
55
+ export interface VariationsResolution {
56
+ type: 'variations';
57
+ variants: PlatformAssetResolution[];
58
+ }
59
+ export type Resolution = AtomicResolution | VariationsResolution;
60
+ /**
61
+ * A tarball URL is git-hosted when it points at a known git provider's immutable
62
+ * archive endpoint. The result gates integrity exemptions, so the match is
63
+ * limited to provider-specific path shapes whose ref is a full commit SHA.
64
+ */
65
+ export declare function isGitHostedTarballUrl(url: string): boolean;
66
+ export type ResolutionKind = 'localTarball' | 'gitHostedTarball' | 'remoteTarball' | 'directory' | 'git' | 'binary' | 'custom';
67
+ /**
68
+ * Classifies a resolution for fetcher selection. Lockfile-provided flags are
69
+ * treated as hints; integrity exemptions depend on the resolved source shape.
70
+ */
71
+ export declare function classifyResolution(resolution: Resolution): ResolutionKind;
72
+ /**
73
+ * Outcome of asking a `ResolutionVerifier` whether a (name, version,
74
+ * resolution) entry from a lockfile is acceptable under whatever policies
75
+ * the resolver chain has been configured with. Resolvers that don't have
76
+ * an opinion on a given resolution should return `{ ok: true }`.
77
+ */
78
+ export type ResolutionVerification = {
79
+ ok: true;
80
+ } | {
81
+ ok: false;
82
+ code: string;
83
+ reason: string;
84
+ };
85
+ /**
86
+ * Optional companion to a resolver factory.
87
+ *
88
+ * `verify` inspects the `resolution` shape to decide whether the entry
89
+ * is within its protocol; for entries outside its protocol it should
90
+ * return `{ ok: true }`. The install side fans out across the verifier
91
+ * list rather than asking a combinator to dispatch.
92
+ *
93
+ * `policy` and `canTrustPastCheck` describe the verifier's cache
94
+ * contract. Policies from every active verifier are merged into a
95
+ * single shared bag stored alongside the lockfile hash; the
96
+ * install-side verification cache reads them to decide if a previous
97
+ * run on the same lockfile is still trustworthy under today's policy
98
+ * without re-issuing the registry round-trips that `verify` would.
99
+ * Verifiers that check the same logical policy (e.g. minimumReleaseAge
100
+ * across registries) name it the same and share the cache slot.
101
+ */
102
+ export interface ResolutionVerifier {
103
+ /**
104
+ * `ctx.nonSemverVersion` is set when the lockfile entry is keyed by a
105
+ * non-semver reference (URL tarball, git, etc.) rather than a registry
106
+ * `name@version`. Verifiers that only police registry entries use it to
107
+ * skip deliberate non-registry deps, which can still carry a semver
108
+ * `version` copied from the resolved manifest.
109
+ */
110
+ verify: (resolution: Resolution, ctx: {
111
+ name: string;
112
+ version: string;
113
+ nonSemverVersion?: string;
114
+ }) => Promise<ResolutionVerification>;
115
+ /**
116
+ * Snapshot of the policy fields this verifier enforces. Merged with
117
+ * every other active verifier's `policy` into the cache record. A
118
+ * field shared across verifiers (same key) should carry the same
119
+ * value; if it doesn't, the last verifier in the list wins.
120
+ */
121
+ policy: Record<string, unknown>;
122
+ /**
123
+ * Returns true when the previously cached policy (the merged snapshot
124
+ * from the last successful run) can be trusted to still satisfy what
125
+ * this verifier currently demands. Reads whichever fields the
126
+ * verifier owns; missing or non-conforming values (e.g. an older
127
+ * record shape) should return false. A loosened policy can trust a
128
+ * stricter cached run; a tightened policy cannot.
129
+ */
130
+ canTrustPastCheck: (cachedPolicy: Record<string, unknown>) => boolean;
131
+ }
132
+ /**
133
+ * A `ResolutionVerifier`'s rejection materialized for one (name,
134
+ * version, resolution) entry. The install side aggregates these across
135
+ * every active verifier on the freshly-resolved tree and either prompts
136
+ * the user, persists them (e.g. into `minimumReleaseAgeExclude`), or
137
+ * aborts. Code is the verifier-defined error code
138
+ * (`MINIMUM_RELEASE_AGE_VIOLATION`, `TRUST_DOWNGRADE`, etc.) — the
139
+ * install command filters by code to decide downstream UX. Lifted here
140
+ * (rather than in deps-installer) so both deps-resolver and
141
+ * deps-installer can share one shape; future resolver packages plug in
142
+ * without needing the deps-installer dependency.
143
+ */
144
+ export interface ResolutionPolicyViolation {
145
+ name: string;
146
+ version: string;
147
+ resolution: Resolution;
148
+ code: string;
149
+ reason: string;
150
+ }
151
+ /** Concrete platform selector used when picking a variant from a VariationsResolution. */
152
+ export interface PlatformSelector {
153
+ os: string;
154
+ cpu: string;
155
+ /** Name of the libc family requested. Omit (or leave `null`) for the default (glibc on Linux, n/a elsewhere). */
156
+ libc?: string | null;
157
+ }
158
+ /**
159
+ * Resolve a {@link PlatformSelector} from the user's supportedArchitectures config
160
+ * and the host's own platform/arch/libc. When `supportedArchitectures.xxx` is set
161
+ * and its first entry is not `"current"`, that entry wins; otherwise the host's
162
+ * value is used. Additional entries beyond the first are ignored — variant
163
+ * selection picks exactly one (os, cpu, libc) triplet per install.
164
+ */
165
+ export declare function resolvePlatformSelector(supportedArchitectures: SupportedArchitectures | undefined, host: {
166
+ platform: string;
167
+ arch: string;
168
+ libc: string | null | undefined;
169
+ }): PlatformSelector;
170
+ /**
171
+ * Pick the variant whose target matches the given selector, or `undefined` if
172
+ * none does. A variant with no `libc` represents the "default" build — glibc on
173
+ * Linux, irrelevant on macOS/Windows. A non-default libc (e.g. `musl`) is a
174
+ * separate, non-interchangeable artifact; an exact libc match is required in
175
+ * that case so the glibc/default variant doesn't silently win (its `target.libc`
176
+ * is nullish).
177
+ */
178
+ export declare function selectPlatformVariant(variants: PlatformAssetResolution[], selector: PlatformSelector): PlatformAssetResolution | undefined;
179
+ export interface ResolveResult {
180
+ id: PkgResolutionId;
181
+ latest?: string;
182
+ publishedAt?: string;
183
+ manifest?: DependencyManifest;
184
+ resolution: Resolution;
185
+ resolvedVia: string;
186
+ normalizedBareSpecifier?: string;
187
+ alias?: string;
188
+ /**
189
+ * Set when the resolver picked this version despite a policy
190
+ * violation (e.g. immature relative to `publishedBy`, trust
191
+ * downgrade detected by `failIfTrustDowngraded`). The resolver
192
+ * already has the metadata it needs to decide, so reporting inline
193
+ * here avoids the install layer having to re-scan the tree and
194
+ * re-fetch the same metadata. The deps-resolver aggregates these
195
+ * across every resolve call into a single set the install command
196
+ * can react to.
197
+ *
198
+ * `resolution` on the violation is the same `resolution` field
199
+ * above — supplied for symmetry with `ResolutionPolicyViolation`
200
+ * entries that flow out of `verifyLockfileResolutions` for
201
+ * lockfile-only paths.
202
+ */
203
+ policyViolation?: ResolutionPolicyViolation;
204
+ }
205
+ export interface WorkspacePackage {
206
+ rootDir: ProjectRootDir;
207
+ manifest: DependencyManifest;
208
+ }
209
+ export type WorkspacePackagesByVersion = Map<string, WorkspacePackage>;
210
+ export type WorkspacePackages = Map<string, WorkspacePackagesByVersion>;
211
+ export declare const DIRECT_DEP_SELECTOR_WEIGHT = 1000;
212
+ export declare const EXISTING_VERSION_SELECTOR_WEIGHT = 1000000;
213
+ export type VersionSelectorType = 'version' | 'range' | 'tag';
214
+ export interface VersionSelectors {
215
+ [selector: string]: VersionSelectorWithWeight | VersionSelectorType;
216
+ }
217
+ export interface VersionSelectorWithWeight {
218
+ selectorType: VersionSelectorType;
219
+ weight: number;
220
+ }
221
+ export interface PreferredVersions {
222
+ [packageName: string]: VersionSelectors;
223
+ }
224
+ export interface ResolveOptions {
225
+ alwaysTryWorkspacePackages?: boolean;
226
+ trustPolicy?: TrustPolicy;
227
+ trustPolicyExclude?: PackageVersionPolicy;
228
+ trustPolicyIgnoreAfter?: number;
229
+ defaultTag?: string;
230
+ pickLowestVersion?: boolean;
231
+ publishedBy?: Date;
232
+ publishedByExclude?: PackageVersionPolicy;
233
+ projectDir: string;
234
+ lockfileDir: string;
235
+ preferredVersions: PreferredVersions;
236
+ preferWorkspacePackages?: boolean;
237
+ workspacePackages?: WorkspacePackages;
238
+ update?: false | 'compatible' | 'latest';
239
+ /**
240
+ * True only when this specific package matches the user's update target
241
+ * (e.g. `pnpm up <name>`). Unlike `update`, this is false for unrelated
242
+ * packages that get re-resolved as a side effect of an update, so it can
243
+ * be used to bypass preferred-version propagation without forcing
244
+ * unrelated transitives to jump to their latest versions.
245
+ */
246
+ updateRequested?: boolean;
247
+ updateChecksums?: boolean;
248
+ injectWorkspacePackages?: boolean;
249
+ calcSpecifier?: boolean;
250
+ pinnedVersion?: PinnedVersion;
251
+ currentPkg?: {
252
+ id: PkgResolutionId;
253
+ name?: string;
254
+ version?: string;
255
+ resolution: Resolution;
256
+ publishedAt?: string;
257
+ };
258
+ }
259
+ export type WantedDependency = {
260
+ injected?: boolean;
261
+ prevSpecifier?: string;
262
+ } & ({
263
+ alias?: string;
264
+ bareSpecifier: string;
265
+ } | {
266
+ alias: string;
267
+ bareSpecifier?: string;
268
+ });
269
+ export type ResolveFunction = (wantedDependency: WantedDependency & {
270
+ optional?: boolean;
271
+ }, opts: ResolveOptions) => Promise<ResolveResult>;
272
+ /**
273
+ * Input to a resolver's `resolveLatest` function. The resolver decides
274
+ * whether it owns this dep purely from `wantedDependency` (its alias and
275
+ * manifest specifier) — the lockfile-resolved ref is the caller's
276
+ * concern, not the resolver's.
277
+ */
278
+ export interface LatestQuery {
279
+ wantedDependency: WantedDependency;
280
+ compatible?: boolean;
281
+ }
282
+ /**
283
+ * Result of a resolver's `resolveLatest` call.
284
+ *
285
+ * - `undefined` means "this resolver does not handle this dep — try
286
+ * the next one".
287
+ * - An object (even without a `latestManifest`) means "I claim this
288
+ * dep, but I can't tell you what's latest" (e.g. policy blocked,
289
+ * network unavailable, no concept of latest for this protocol).
290
+ * The caller still surfaces a ref-mismatch report if the lockfile
291
+ * shifted.
292
+ */
293
+ export interface LatestInfo {
294
+ latestManifest?: PackageManifest;
295
+ }
296
+ export type ResolveLatestFunction = (query: LatestQuery, opts: ResolveOptions) => Promise<LatestInfo | undefined>;
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@pnpm/resolving.resolver-base",
3
- "version": "1100.5.3",
3
+ "version": "1100.5.5",
4
4
  "description": "Types for pnpm-compatible resolvers",
5
5
  "keywords": [
6
6
  "pnpm",
@@ -28,11 +28,11 @@
28
28
  "!*.map"
29
29
  ],
30
30
  "dependencies": {
31
- "@pnpm/types": "1101.5.0"
31
+ "@pnpm/types": "1101.7.0"
32
32
  },
33
33
  "devDependencies": {
34
34
  "@jest/globals": "30.4.1",
35
- "@pnpm/resolving.resolver-base": "1100.5.3"
35
+ "@pnpm/resolving.resolver-base": "1100.5.5"
36
36
  },
37
37
  "engines": {
38
38
  "node": ">=22.13"