chore: require npm versions to be 7 days old before resolution

[kparkinson-ld]

Summary

Follow-up to #705, from the SEC-8921 investigation of the npm account-takeover campaign that hijacked keyv, cache-manager, cacheable-request and ~39 other packages (Wiz wiz-adv-2026-138). #705 stopped hijacked packages from executing install scripts; this stops us from resolving a version that was published minutes ago, which is the window these campaigns live in — malicious versions are typically yanked within hours.

  nodeLinker: node-modules

+ # Only resolve package versions published more than 7 days ago. Exempt packages
+ # via npmPreapprovedPackages.
+ npmMinimalAgeGate: 7d
+
  yarnPath: .yarn/releases/yarn-4.13.0.cjs

npmMinimalAgeGate is native to yarn (added in 4.10.0); this repo is already on 4.13.0, so no yarn bump is needed here. 7 days per @pkaeding's review — it matches the default-days: 7 dependabot cooldown used in 15 of the 16 org repos that configure one, and comfortably covers npm's 72-hour unpublish window, so we also stop depending on versions that can still vanish. (gonfalon's renovate hold is 3 days and is the outlier; worth reconciling separately.)

What it does and doesn't do:

• Resolution-time only. Existing yarn.lock entries install normally, including versions younger than the gate. Nothing already pinned breaks.
• Applies to every install path — yarn add on a laptop as well as CI — unlike a renovate/dependabot cooldown, which only gates bot PRs.
• Adding a dependency whose only matching version is too new fails loudly: YN0016: ... All versions satisfying "x.y.z" are quarantined. npmPreapprovedPackages is the documented escape hatch; nothing needs it today.
• Workspace packages are unaffected — the e2e apps consume highlight.run / @launchdarkly/* via workspace:*, not from the registry, so our own just-published releases are never gated. No workflow here installs a freshly published version from npm.

Cost: picking up a genuine upstream fix (including a Dependabot security bump) can be delayed up to 7 days. Preapprove the package or lower the value if that ever bites.

How did you test this change?

• yarn config get npmMinimalAgeGate → 10080 (minutes).
• yarn install --immutable — clean, no lockfile churn, no quarantine errors.
• yarn dedupe --check and yarn format-check — both pass (the CI steps most likely to be perturbed by a resolver change).
• Separately, in a scratch project on the same yarn 4.13.0 binary: yarn add @aws-sdk/client-s3 resolved an older version and refused a recently published one, confirming the gate is actually enforced rather than silently ignored.

Are there any deployment considerations?

No. Config-only; no runtime or published-artifact change.

Link to Devin session: https://app.devin.ai/sessions/6bf8e18507f94eed85e5c0a806f691ed
Requested by: @kparkinson-ld

---

Note

Overview
Adds npmMinimalAgeGate: 7d to .yarnrc.yml so Yarn only resolves npm package versions published at least seven days ago, complementing the existing enableScripts: false supply-chain controls.

Existing yarn.lock pins are unchanged; the gate applies when adding or bumping dependencies (local yarn add and CI alike). Versions that are too new fail with a quarantine error unless exempted via npmPreapprovedPackages. Workspace workspace:* packages are not affected.

^{Reviewed by Cursor Bugbot for commit 6ee65a3. Bugbot is set up for automated code reviews on this repo. Configure here.}

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

@cursor review

[pkaeding]

Should we extend this to 7d, to match our dependabot cooldown policy?

[devin-ai-integration]

Should we extend this to 7d, to match our dependabot cooldown policy?

Yes — agreed, and the data backs it: of the 16 repos in the org that configure a dependabot cooldown, 15 use default-days: 7 (the lone exception is vercel-marketplace-integration at 3), and launchpad-ui also uses 7d for its pnpm minimumReleaseAge. My 3d came from gonfalon's renovate hold, which turns out to be the outlier.

Raised to 7d here (6ee65a3) and in the paired observability#1673. Nothing needs npmPreapprovedPackages at 7d either — the e2e apps consume our own packages via workspace:*, so our just-published releases aren't self-gated.

Worth reconciling gonfalon's 3d renovate hold separately so the org lands on one number; tracking under SEC-8921.