fix: drop prefer-offline from .npmrc to avoid stale-cache ETARGET - #2617
Open
davedittrich wants to merge 1 commit into
Open
fix: drop prefer-offline from .npmrc to avoid stale-cache ETARGET#2617davedittrich wants to merge 1 commit into
davedittrich wants to merge 1 commit into
Conversation
prefer-offline bypasses staleness checks on cached registry metadata, so npm resolves against a packument that can predate versions the lockfile requires. With esbuild pinned to ^0.28.1 (overrides, bmad-code-org#2493) and a cache topping out at 0.27.2, npm install fails: npm error code ETARGET npm error notarget No matching version found for esbuild@^0.28.1 The failure is silent and machine-dependent: it only reproduces on clones whose cache went stale before the pin landed, so CI stays green while contributors hit a hard install error. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
💤 Files with no reviewable changes (1)
📝 WalkthroughWalkthroughThe Changesnpm install configuration
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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
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.
prefer-offline bypasses staleness checks on cached registry metadata, so npm resolves against a packument that can predate versions the lockfile requires. With esbuild pinned to ^0.28.1 (overrides, #2493) and a cache topping out at 0.27.2, npm install fails:
npm error code ETARGET
npm error notarget No matching version found for esbuild@^0.28.1
The failure is silent and machine-dependent: it only reproduces on clones whose cache went stale before the pin landed, so CI stays green while contributors hit a hard install error.
What
Removes
prefer-offline=truefrom.npmrc.Why
prefer-offlinebypasses staleness checks on cached registry metadata — npm onlyreaches the network for packuments it is missing entirely, never to revalidate one
it already has. That means a clone can resolve dependencies against a cached view
of the registry that predates versions the lockfile requires.
This is currently reachable on
main. #2493 pinnedesbuildto^0.28.1viaoverrides. On a machine whose cachedesbuildpackument predates that release,npm installfails outright:npm error code ETARGET
npm error notarget No matching version found for esbuild@^0.28.1.
Reproduced locally, where the cached packument topped out at
0.27.2:$ npm view esbuild version # in-repo, prefer-offline on
0.27.2
$ npm view esbuild version --prefer-offline=false # actual registry
0.28.1
Two things make this worth fixing rather than papering over:
fresh metadata and always pass. Only contributors with an aged cache hit it.
npm audit fix. With stale metadata npm cannot see the fixedreleases, so it proposes downgrades instead — on this repo
npm audit fix --forceoffered to take eslint 9 → 4, jest 30 → 25, andmarkdownlint-cli2 0.19 → 0.12.
The comment describes the flag as an install-performance tweak. The speed gain is
small, and it is paid for with non-reproducible resolution.
How
prefer-offline=trueand its comment from.npmrclegacy-peer-deps=trueuntouchedTesting
With the flag removed,
npm installresolvesesbuild@0.28.1cleanly on thepreviously-failing machine. Verified against
mainatbb45db4a:npm run docs:buildsucceeds, andtest:refs,test:install,test:urls,test:channels,test:renderer,test:skillsall pass.