feat(cli): make the lockfile prune resilient to slow registries [RED-930] [ship] - #1471
Merged
Conversation
The lockfile pruner regenerates the lockfile against manifests that deliberately differ from it, so pnpm never takes its resolution-skipped fast path and needs registry metadata for anything it cannot serve from the store. Without the flag, range and catalog specs and optional dependencies are re-fetched on every prune; behind a slow or intercepting proxy one stalled request exceeds the prune budget and the fallback ships a stale lockfile that fails on the runner. With --prefer-offline, pnpm and npm use cached metadata for any spec type and only contact the registry for misses. A stale cache can only change a fresh resolution, which the pruner's subset verification rejects, so the worst case remains a fallback. Verified on pnpm 10 and 11 that the flag is not recorded in the lockfile's settings section. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…out [RED-930] When the lockfile prune's package manager child timed out, its output was discarded, which made a stalled registry request impossible to diagnose. The redacted tail of the child's stdout and stderr is now logged on the pruner's debug channel for both the yarn version probe and the install. Redaction follows the by-construction rule already used for embedded packages, collapsing every URL to scheme and host via redactUrl, since registry tokens travel in userinfo, query strings and path segments alike. The user-facing failure reason shares the same redaction. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…e prune timeout [RED-930] The lockfile prune's 30 s budget was hardcoded, so a machine with a cold metadata cache behind a slow registry had no way to let the prune finish short of disabling pruning altogether. The variable takes whole seconds (0 disables the timeout); unusable values are ignored and noted on the debug channel. The timeout failure reasons now name the variable, so the bundler's fallback warning shows the remedy where the timeout is reported. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
sorccu
force-pushed
the
simo/red-930-pnpm-prune-prefer-offline
branch
from
September 4, 2026 10:59
4673f83 to
b9e0c97
Compare
sorccu
changed the title
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Linear: RED-930
The lockfile pruner runs the package manager's lockfile-only install against manifests that deliberately differ from the lockfile, so pnpm re-resolves and needs registry metadata for anything it cannot serve from the store. On pnpm 10, range and catalog specs and optional dependencies are re-fetched on every prune unless
prefer-offlineis set. Behind a slow or intercepting proxy a single stalled request exceeds the 30 s prune budget, the pruner falls back to shipping the original lockfile next to faux manifests, and the runner install fails withERR_PNPM_OUTDATED_LOCKFILE.Changes
--prefer-offlineon the pnpm and npm lockfile-only commands. pnpm and npm then use cached metadata for any spec type and only contact the registry for misses. The soft flag is deliberate: a cold cache is a legitimate first-prune state, and--offlinewould turn it into a guaranteed fallback. A stale cache can only change a fresh resolution, which the pruner's subset verification rejects, so the worst case stays a fallback. Verified on pnpm 10.33.4 and 11.22.0 that the flag is not recorded in the lockfile'ssettingssection. Yarn and bun are unchanged.checkly:cli:services:check-parser:lockfile-prunerdebug channel, for both the yarn version probe and the install. Redaction reuses the existing by-constructionredactUrl(every URL collapses to scheme and host), and the user-facing failure reason now shares that redaction.CHECKLY_LOCKFILE_PRUNE_TIMEOUT. Overrides the hardcoded 30 s budget, in whole seconds (0disables the timeout). Unusable values are ignored and noted on the debug channel. The timeout failure reasons name the variable, so the bundler's fallback warning shows the remedy.Other changes
--config.comment inPNpmDetector.lockfileOnlyInstallCommand()claimed the pruner compares the lockfilesettingssection. It does not; the comment now states the actual hazard (a recorded setting ships to the runner unchecked).captureStderrmoved frommaterializer.spec.tstosrc/testing/capture-stderr.tsso both specs share it.🤖 Generated with Claude Code