Description

The new logic explicitly awaits fetching() to read the bundled manifest for optional dependencies
whose registry/lockfile metadata lacks os/cpu/libc, which can still download non-matching
platform binaries even when supportedArchitectures is configured. This violates the requirement to
avoid fetching/downloading platform-incompatible optional binaries.

Code

installing/package-requester/src/packageRequester.ts[R316-336]

+    wantedDependency.optional === true &&
+    manifest.os == null && manifest.cpu == null && manifest.libc == null
+  ) {
+    // Registry metadata is not guaranteed to carry os/cpu/libc — some
+    // registries strip them from packument version objects. For an optional
+    // dependency that looks platform-unrestricted, trust the manifest bundled
+    // in the fetched tarball instead: without this, platform-specific optional
+    // dependencies would be installed on every platform and the lockfile would
+    // be written without the platform fields, breaking installs everywhere.
+    // https://github.com/pnpm/pnpm/issues/11702
+    const { bundledManifest } = await fetchResult.fetching()
+    if (bundledManifest != null && (bundledManifest.os != null || bundledManifest.cpu != null || bundledManifest.libc != null)) {
+      manifest = { ...manifest, os: bundledManifest.os, cpu: bundledManifest.cpu, libc: bundledManifest.libc }
+      recheckInstallability = true
+    }
}
-  // Check installability now that we have the manifest (for git/tarball packages without registry metadata)
-  if (isInstallable === undefined && manifest != null) {
+  // Check installability using the fetched manifest — either the registry
+  // metadata had none (git/tarball packages), or it was missing the
+  // platform fields that the bundled manifest declares.
+  if (recheckInstallability && manifest != null) {
  isInstallable = ctx.force === true || packageIsInstallable(id, manifest, {

Evidence

PR Compliance IDs 1 and 2 require that when supportedArchitectures is set, pnpm must not
download/fetch platform-incompatible optional binaries. The added code explicitly triggers
fetchRawManifest and then awaits fetching() to consult the bundled manifest for optional deps
missing platform fields, meaning the tarball may be downloaded before installability is determined
and the dep is skipped.

Respect supportedArchitectures during dependency installation (do not fetch non-matching platform binaries)
Filter optionalDependencies (e.g., esbuild) according to supportedArchitectures
installing/package-requester/src/packageRequester.ts[316-336]
deps/graph-builder/src/lockfileToDepGraph.ts[286-327]
installing/deps-restorer/src/lockfileToHoistedDepGraph.ts[248-290]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
New code paths fetch optional dependency tarballs (via `fetching()`) to discover missing `os`/`cpu`/`libc` fields, which can still download platform-incompatible binaries under `supportedArchitectures`.
## Issue Context
Compliance requires pnpm to not fetch/download optional, platform-specific binaries that do not match the configured `supportedArchitectures`.
## Fix Focus Areas
- installing/package-requester/src/packageRequester.ts[316-336]
- deps/graph-builder/src/lockfileToDepGraph.ts[286-327]
- installing/deps-restorer/src/lockfileToHoistedDepGraph.ts[248-290]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

In lockfileToDepGraph, the bundled-manifest platform verification only runs inside the fetch path,
so when a package hits the “present/unchanged” fast paths (or early-returns), an optional dep whose
lockfile entry lacks os/cpu/libc won’t be revalidated and can remain installed. This undermines the
intended healing behavior for existing broken lockfiles when node_modules is reused across installs.

Code

deps/graph-builder/src/lockfileToDepGraph.ts[R286-328]

+        // A lockfile entry of an optional dependency without any platform
+        // fields may have been written from registry metadata that strips
+        // os/cpu/libc, so the bundled manifest of the fetched package has to
+        // be consulted before the package is linked to node_modules.
+        // https://github.com/pnpm/pnpm/issues/11702
+        const verifyPlatformOfFetchedPkg = !opts.force &&
+          !isDirectoryDep &&
+          pkgSnapshot.optional === true &&
+          pkgSnapshot.os == null && pkgSnapshot.cpu == null && pkgSnapshot.libc == null
      try {
        fetchResponse = await opts.storeController.fetchPackage({
          allowBuild: opts.allowBuild,
          force: false,
+            fetchRawManifest: verifyPlatformOfFetchedPkg,
          lockfileDir: opts.lockfileDir,
          ignoreScripts: opts.ignoreScripts,
          pkg: { name: pkgName, version: pkgVersion, id: packageId, resolution },
          supportedArchitectures: opts.supportedArchitectures,
        })
+          if (verifyPlatformOfFetchedPkg && fetchResponse.fetching != null) {
+            const { bundledManifest } = await fetchResponse.fetching()
+            if (
+              bundledManifest != null &&
+              (bundledManifest.os != null || bundledManifest.cpu != null || bundledManifest.libc != null) &&
+              packageIsInstallable(packageId, {
+                name: pkgName,
+                version: pkgVersion,
+                os: bundledManifest.os,
+                cpu: bundledManifest.cpu,
+                libc: bundledManifest.libc,
+              }, {
+                engineStrict: opts.engineStrict,
+                lockfileDir: opts.lockfileDir,
+                nodeVersion: opts.nodeVersion,
+                optional: true,
+                supportedArchitectures: opts.supportedArchitectures,
+              }) === false
+            ) {
+              delete locationByDepPath[depPath]
+              opts.skipped.add(depPath)
+              return
+            }
+          }

Evidence

The code sets fetchResponse = {} (and may return early) when the package is already
present/unchanged, which prevents entering the if (!fetchResponse) block where the new
bundled-manifest platform verification is implemented. Also, missing platform fields are treated as
unrestricted by installability checks, so without the bundled-manifest recheck these deps appear
installable.

deps/graph-builder/src/lockfileToDepGraph.ts[196-215]
deps/graph-builder/src/lockfileToDepGraph.ts[246-280]
deps/graph-builder/src/lockfileToDepGraph.ts[282-333]
config/package-is-installable/src/index.ts[68-93]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`lockfileToDepGraph` only performs the new bundled-manifest platform recheck when it calls `storeController.fetchPackage()`. If the package is considered already present/unchanged (fast-path sets `fetchResponse = {}`) or the function returns early, the recheck never happens, so optional deps with missing `os/cpu/libc` in the lockfile may stay installed even though their bundled manifest would mark them unsupported.
### Issue Context
This PR adds platform verification using the bundled manifest for optional deps when lockfile snapshot lacks `os/cpu/libc`. However, existing fast paths can prevent any fetch/read of the bundled manifest and thus skip the new verification.
### Fix Focus Areas
- deps/graph-builder/src/lockfileToDepGraph.ts[246-333]
### Implementation notes
- When `pkgSnapshot.optional === true` and `pkgSnapshot.os/cpu/libc` are all missing, bypass the “present/unchanged” early-return and `{}` fetchResponse fast paths so that the bundled manifest can be consulted.
- Prefer a cheap read:
- If the package is already in the store, calling `storeController.fetchPackage({ fetchRawManifest: true, ... })` should read from store without re-downloading.
- Alternatively, if the package directory is present, read `package.json` from that directory to obtain `os/cpu/libc` and run `packageIsInstallable`.
- If unsupported, ensure the depPath is added to `opts.skipped` and any precomputed location mapping is removed so pruning can clean it up.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

In lockfileToHoistedDepGraph, the new bundled-manifest platform verification is only executed when
skipFetch is false; if a package is already present in the expected hoisted location, it skips
fetching and therefore skips the platform revalidation. With a broken lockfile entry missing
os/cpu/libc, this can leave incompatible optional packages hoisted across subsequent installs.

Code

installing/deps-restorer/src/lockfileToHoistedDepGraph.ts[R248-290]

+      // A lockfile entry of an optional dependency without any platform
+      // fields may have been written from registry metadata that strips
+      // os/cpu/libc, so the bundled manifest of the fetched package has to
+      // be consulted before the package is linked to node_modules.
+      // https://github.com/pnpm/pnpm/issues/11702
+      const verifyPlatformOfFetchedPkg = !opts.force &&
+        !isDirectoryDep &&
+        pkgSnapshot.optional === true &&
+        pkgSnapshot.os == null && pkgSnapshot.cpu == null && pkgSnapshot.libc == null
    try {
      fetchResponse = opts.storeController.fetchPackage({
        allowBuild: opts.allowBuild,
        force: false,
+          fetchRawManifest: verifyPlatformOfFetchedPkg,
        lockfileDir: opts.lockfileDir,
        ignoreScripts: opts.ignoreScripts,
        pkg: pkgResolution,
        supportedArchitectures: opts.supportedArchitectures,
      }) as unknown as ReturnType<FetchPackageToStoreFunction>
      if (fetchResponse instanceof Promise) fetchResponse = await fetchResponse
+        if (verifyPlatformOfFetchedPkg && fetchResponse.fetching != null) {
+          const { bundledManifest } = await fetchResponse.fetching()
+          if (
+            bundledManifest != null &&
+            (bundledManifest.os != null || bundledManifest.cpu != null || bundledManifest.libc != null) &&
+            packageIsInstallable(packageId, {
+              name: pkgName,
+              version: pkgVersion,
+              os: bundledManifest.os,
+              cpu: bundledManifest.cpu,
+              libc: bundledManifest.libc,
+            }, {
+              engineStrict: opts.engineStrict,
+              lockfileDir: opts.lockfileDir,
+              nodeVersion: opts.nodeVersion,
+              optional: true,
+              supportedArchitectures: opts.supportedArchitectures,
+            }) === false
+          ) {
+            opts.skipped.add(depPath)
+            return
+          }
+        }

Evidence

skipFetch is computed and if true the code avoids the fetch branch entirely. The new
bundled-manifest platform recheck lives only in that fetch branch, so it never runs for reused
hoisted packages, while missing platform fields are treated as unrestricted.

installing/deps-restorer/src/lockfileToHoistedDepGraph.ts[233-291]
config/package-is-installable/src/index.ts[68-93]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
In `fetchDeps` (hoisted linker), `verifyPlatformOfFetchedPkg` is only applied in the `else` branch when `skipFetch` is false. When `skipFetch` is true (package already present), platform constraints are not rechecked, so optional deps whose lockfile snapshots lack `os/cpu/libc` can remain installed even if their bundled manifest is incompatible.
### Issue Context
This PR aims to make installs resilient to stripped `os/cpu/libc` in lockfiles by consulting the bundled manifest. The hoisted reuse fast path currently bypasses this consultation.
### Fix Focus Areas
- installing/deps-restorer/src/lockfileToHoistedDepGraph.ts[233-295]
### Implementation notes
- For `pkgSnapshot.optional === true` and missing `os/cpu/libc`, perform verification even when `skipFetch` is true:
- Option A: read `package.json` from the existing hoisted directory and extract `os/cpu/libc`.
- Option B: call `storeController.fetchPackage({ fetchRawManifest: true, ... })` even on skipFetch (should be store-local if already present), then run `packageIsInstallable` using `bundledManifest`.
- If unsupported, add `depPath` to `opts.skipped` so later pruning/linking logic can remove it.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

inferPlatformFromPackageName does not treat a bare "64" token as x64, so packages whose names use
the “-<os>-64” convention (e.g. turbo-windows-64, esbuild-darwin-64) infer only an OS and remain
installable on any CPU for that OS when cpu metadata is missing. Since checkPlatform only validates
CPU when wantedPlatform.cpu is present, supportedArchitectures.cpu may not filter these optional
binaries on mismatched architectures.

Code

config/package-is-installable/src/inferPlatformFromPackageName.ts[R17-33]

+const CPU_BY_TOKEN = new Map([
+  ['arm', 'arm'],
+  ['armv6', 'arm'],
+  ['armv7', 'arm'],
+  ['arm64', 'arm64'],
+  ['aarch64', 'arm64'],
+  ['ia32', 'ia32'],
+  ['loong64', 'loong64'],
+  ['mips64el', 'mips64el'],
+  ['ppc64', 'ppc64'],
+  ['ppc64le', 'ppc64'],
+  ['riscv64', 'riscv64'],
+  ['s390x', 's390x'],
+  ['x64', 'x64'],
+  ['amd64', 'x64'],
+  ['wasm32', 'wasm32'],
+])

Evidence

The CPU token map has no entry for a bare 64, while tests include turbo-windows-64 and
esbuild-darwin-64 and therefore currently infer no CPU. checkPlatform() only checks CPU when
wantedPlatform.cpu is provided, so missing CPU inference bypasses CPU filtering when
registry/lockfile metadata is stripped.

config/package-is-installable/src/inferPlatformFromPackageName.ts[17-33]
config/package-is-installable/test/inferPlatformFromPackageName.ts[15-25]
config/package-is-installable/src/checkPlatform.ts[29-40]
pacquet/crates/package-is-installable/src/infer_platform_from_package_name.rs[22-35]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Some platform-specific optional binary packages encode x64 as a bare `64` token in their name (e.g. `turbo-windows-64`, `esbuild-darwin-64`). The current token map does not recognize `64`, so inference omits `cpu`, and CPU compatibility is never checked.

### Issue Context
- `checkPlatform()` only enforces CPU when `wantedPlatform.cpu` is set.
- The test suite already includes real-world `*-*-64` names, which currently infer OS only.

### Fix Focus Areas
- Add a conservative heuristic to infer `cpu: ['x64']` from a `64` token **only when** an OS token is also present (to avoid generic false positives), and when no other CPU token is present.
- Apply the same logic in both the TypeScript implementation and the pacquet Rust port.
- Extend/adjust unit tests to cover the new behavior.

- config/package-is-installable/src/inferPlatformFromPackageName.ts[17-33]
- config/package-is-installable/test/inferPlatformFromPackageName.ts[15-25]
- pacquet/crates/package-is-installable/src/infer_platform_from_package_name.rs[22-35]
- pacquet/crates/package-is-installable/src/tests/infer_platform_from_package_name.rs[24-55]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new optional-deps e2e test calls http.Server.close() in a finally block without awaiting
completion, which can leave open handles and cause Jest to warn or flake depending on timing. This
is inconsistent with other repo tests that explicitly await server shutdown.

Code

installing/deps-installer/test/install/optionalDependencies.ts[R152-167]

+  await new Promise<void>((resolve) => {
+    server.listen(0, resolve)
+  })
+  const registryProxy = `http://localhost:${(server.address() as AddressInfo).port}/`
+  try {
+    await install({
+      dependencies: {
+        '@pnpm.e2e/has-many-optional-deps': '1.0.0',
+      },
+    }, testDefaults({
+      registries: { default: registryProxy },
+      supportedArchitectures: { os: ['darwin'], cpu: ['arm64'] },
+    }))
+  } finally {
+    server.close()
+  }

Evidence

The new test does not await server closure, while other tests in-repo explicitly await
server.close() to avoid leaked handles.

installing/deps-installer/test/install/optionalDependencies.ts[148-167]
pnpm/test/install/pnpmRegistry.ts[54-56]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The test `skip optional dependencies ... when the registry metadata has no platform fields` starts an `http.Server` and calls `server.close()` in `finally` without waiting for the close to complete. This may keep open handles briefly after the test finishes.
### Issue Context
`http.Server.close()` is asynchronous; other tests in this repo wrap `server.close()` in a Promise and `await` it.
### Fix Focus Areas
- installing/deps-installer/test/install/optionalDependencies.ts[148-167]
### Suggested change
In the `finally` block, replace `server.close()` with:

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

createMetadataStrippingRegistryProxy() forwards all incoming requests upstream using fetch() without
preserving req.method, so HEAD/other methods are silently converted into GET. This makes the proxy
semantically incorrect vs real registry interactions and could break if the install path uses HEAD
requests (which pnpm does in other resolution flows).

Code

installing/deps-installer/test/install/optionalDependencies.ts[R186-204]

+  return http.createServer((req, res) => {
+    (async () => {
+      const upstream = await fetch(`http://localhost:${REGISTRY_MOCK_PORT}${req.url}`, {
+        headers: { accept: req.headers.accept ?? '*/*' },
+      })
+      const contentType = upstream.headers.get('content-type') ?? ''
+      if (contentType.includes('json')) {
+        const doc = await upstream.json() as { versions?: Record<string, Record<string, unknown>> }
+        for (const versionMeta of Object.values(doc.versions ?? {})) {
+          delete versionMeta.os
+          delete versionMeta.cpu
+          delete versionMeta.libc
+        }
+        res.writeHead(upstream.status, { 'content-type': 'application/json' })
+        res.end(JSON.stringify(doc))
+      } else {
+        res.writeHead(upstream.status, { 'content-type': contentType })
+        res.end(Buffer.from(await upstream.arrayBuffer()))
+      }

Evidence

The proxy currently issues an upstream fetch without preserving the inbound HTTP method. pnpm
codebase contains HEAD-based registry interactions, and other in-repo proxy code forwards `method:
req.method`, demonstrating the expected proxying behavior.

installing/deps-installer/test/install/optionalDependencies.ts[185-204]
resolving/tarball-resolver/src/index.ts[10-28]
pnpm/test/install/pnpmRegistry.ts[34-37]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The test registry proxy forwards requests to the upstream registry mock using `fetch(...)` but does not include `method: req.method`. This means any HEAD request becomes a GET upstream.
### Issue Context
pnpm does use HEAD requests in some registry/tarball resolution flows, so the proxy should be correct and future-proof.
### Fix Focus Areas
- installing/deps-installer/test/install/optionalDependencies.ts[185-204]
### Suggested change
Pass through the incoming method (and optionally body for non-GET/HEAD) when calling `fetch`:

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The metadata-stripping proxy passes req.headers.accept directly into fetch() headers, but Node
types it as string | string[] | undefined and it may be an array at runtime. Normalizing to a
string avoids type-safety issues and prevents sending an unexpected header value.

Code

installing/deps-installer/test/install/optionalDependencies.ts[R182-184]

+      const upstream = await fetch(`http://localhost:${REGISTRY_MOCK_PORT}${req.url}`, {
+        headers: { accept: req.headers.accept ?? '*/*' },
+      })

Evidence

The proxy currently forwards req.headers.accept without handling the string[] case, which is a
valid shape for Node incoming headers and can also be rejected by stricter typing/tooling.

installing/deps-installer/test/install/optionalDependencies.ts[177-199]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`req.headers.accept` can be `string | string[] | undefined`, but the proxy forwards it into `fetch()` as if it were always a string.
### Issue Context
This is test-only code, but normalizing prevents TS friction and makes the proxy behavior explicit.
### Fix Focus Areas
- installing/deps-installer/test/install/optionalDependencies.ts[179-184]
### Implementation notes
Example:

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

🐞 Bugs (5) 📘 Rule violations (0) 📎 Requirement gaps (1)

🐞 Bugs (3) 📘 Rule violations (0) 📎 Requirement gaps (1)

Walkthrough

Infers missing os/cpu/libc for optional dependencies from package names and uses those inferred fields in installability checks so platform-specific optional packages are skipped when incompatible.

Changes

Platform Field Inference for Optional Dependencies

Sequence Diagram

sequenceDiagram
  participant Client
  participant PackageRequester
  participant effectivePlatform
  participant inferPlatformFromPackageName
  participant checkPackage

  Client->>PackageRequester: request optional dep (package name)
  PackageRequester->>PackageRequester: obtain manifest (os/cpu/libc missing)
  PackageRequester->>effectivePlatform: build effective manifest for optional dep
  effectivePlatform->>inferPlatformFromPackageName: infer {os,cpu,libc} from name
  inferPlatformFromPackageName->>effectivePlatform: return inferred platform
  effectivePlatform->>checkPackage: run checkPackage with enriched manifest
  checkPackage->>PackageRequester: return installability verdict
  PackageRequester->>Client: skip download if not installable

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related issues

• Proper optionalDependencies support — umbrella pacquet#434: Implements name-based platform inference and related installability semantics addressed here.
• Install respects every snapshot — no os/cpu/libc filter for optional deps pacquet#266: Related to skipping optional snapshots when platform constraints (declared or inferred) apply.
• Write a filtered current lockfile (#434 slice 6) pacquet#493: Touches skipped-snapshots logic connected to these changes.

Possibly related PRs

• pnpm/pnpm#11725: Updates config/package-is-installable for optional dependency platform inference and is directly related to these changes.

"🐰 I hop through names and tokens clear,
I sniff for win, linux, arm, or mear;
If your bin won't run on this machine,
I skip the fetch and keep things clean —
No extra weight, just what belongs here."

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

• X
• Mastodon
• Reddit
• LinkedIn

• Re-check optional dependency installability using tarball manifest when metadata lacks platform
  fields.
• Heal lockfiles by writing os/cpu/libc so subsequent installs skip incompatible binaries.
• Add unit + e2e coverage for metadata-stripping registries and broken lockfiles.

The following are alternative approaches to this PR:

Recommendation: Keep the PR’s conditional strategy: only consult the tarball manifest for optional deps that appear platform-unrestricted due to missing os/cpu/libc. This minimizes overhead on healthy registries while correctly skipping incompatible binaries and repairing lockfiles so future installs become fast and deterministic.

lockfileToDepGraph.ts Verify platform for optional deps when lockfile snapshot lacks os/cpu/libc +34/-0

Verify platform for optional deps when lockfile snapshot lacks os/cpu/libc

• During dep graph construction, detects optional lockfile entries missing all platform fields and requests the raw manifest during store fetch. If the bundled manifest declares platform constraints and the package is not installable, the dep path is removed from locations and added to the skipped set before linking.

deps/graph-builder/src/lockfileToDepGraph.ts

---

lockfileToHoistedDepGraph.ts Re-check optional dep installability from fetched manifest in hoisted restorer +33/-0

Re-check optional dep installability from fetched manifest in hoisted restorer

• For hoisted headless installs, detects optional snapshots missing platform fields and fetches the raw bundled manifest before linking. Uses packageIsInstallable to skip incompatible optionals and records them in the skipped set, preventing incorrect node_modules materialization from broken lockfiles.

installing/deps-restorer/src/lockfileToHoistedDepGraph.ts

---

packageRequester.ts Merge bundled manifest platform fields and re-check optional installability +21/-2

Merge bundled manifest platform fields and re-check optional installability

• When an optional dependency’s resolved manifest lacks os/cpu/libc, awaits the tarball fetch and merges platform fields from the bundled manifest into the returned manifest. Re-runs packageIsInstallable using the fetched/merged manifest so incompatible optionals are marked not installable and the lockfile receives the correct platform fields.

installing/package-requester/src/packageRequester.ts

---

optionalDependencies.ts Add e2e coverage for metadata-stripping registries and broken lockfiles +128/-0

Add e2e coverage for metadata-stripping registries and broken lockfiles

• Adds an HTTP proxy that strips os/cpu/libc from registry JSON responses and verifies incompatible optional deps are skipped while the lockfile gains the missing platform fields. Adds frozen-install tests (isolated + hoisted) where lockfile snapshots are manually stripped, ensuring only matching-platform optionals are materialized and others are recorded as skipped.

installing/deps-installer/test/install/optionalDependencies.ts

---

index.ts Unit test: optional installability determined from fetched manifest when metadata stripped +39/-0

Unit test: optional installability determined from fetched manifest when metadata stripped

• Adds a test wrapper around the resolver that deletes os/cpu/libc from the resolved manifest. Asserts the package requester marks the optional dependency as not installable and returns platform fields sourced from the fetched tarball manifest so they can be written into the lockfile.

installing/package-requester/test/index.ts

---

spicy-pots-wonder.md Add changeset documenting optional-dep platform-field healing +8/-0

Add changeset documenting optional-dep platform-field healing

• Adds a patch changeset for the affected packages and pnpm. Documents the behavior change: use tarball manifest to skip incompatible optional deps and write os/cpu/libc into the lockfile even when registry metadata is stripped.

.changeset/spicy-pots-wonder.md

---

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.