feat(npm): write min-release-age-exclude entries for security updates

[MorrisonCole]

How are you running Renovate?

A Mend.io-hosted app

Which platform you running Renovate on?

GitHub.com

Which version of Renovate are you using?

44.12.0

Please tell us more about your question or problem

This discussion originally covered both npm and Yarn. The Yarn half is split out into #45279 which is actionable today; this one is now npm-only, where the upstream setting can't yet properly express what's needed. I've raised https://github.com/orgs/community/discussions/204502 upstream where discussion needs to happen first.

When min-release-age is set in a project, Renovate security updates that resolve to a version younger than the gate should record that version as approved by adding an entry to min-release-age-exclude in .npmrc, the same way Renovate already does for pnpm's minimumReleaseAgeExclude (#39168):

min-release-age=7
min-release-age-exclude[]=axios // note this does *NOT support version scoping*, we need to advocate for / get https://github.com/orgs/community/discussions/204502 solved first!

Why it's needed

npm applies the gate when it resolves a package, not when it installs from the lockfile. npm ci is fine after a security update merges - the problem is the next thing that re-resolves. Verified on npm 12.0.2, with a security fix already locked:

	npm 12.0.2
npm ci, cold cache	installs locked version
plain install, lockfile in sync	installs locked version
explicit npm install <pkg>, range permits an older version	silent downgrade
explicit npm install <pkg>, range pins the fix	ETARGET
version-scoped exclusion entry	silently matches nothing

So after a security fix lands, a developer running npm install <pkg> either hits a hard error or silently reverts the fix.

Why npm is blocked, and pnpm/Yarn aren't

min-release-age-exclude matches package names and minimatch globs only - there's no pkg@version form. The most Renovate could write today is the bare package name, which would exempt that package from the gate permanently rather than approving the one audited version. An entry that does carry a version isn't rejected either: it parses fine and matches nothing, so it silently exempts nothing.

That makes automatic writes riskier than they're worth for npm right now. I've raised the missing version-scoped form upstream in https://github.com/orgs/community/discussions/204502 - if npm gains it, this becomes the same change as the pnpm and Yarn ones.

Logs (if relevant)

No response

[RahulGautamSingh]

Could you also post how the work that needs to be done for it i.e. in which files we should add the exclusion settings/fields. For example, in pnpm's case we could just add the minimumReleaseAgeExclude to the pnpm workspace file. What is the equivalent for npm and yarn?

[MorrisonCole]

Sure! Both live in the package manager's own config files (same as pnpm's pnpm-workspace.yaml)

npm: .npmrc

min-release-age=7
min-release-age-exclude[]=axios

• min-release-age-exclude - added in 11.17.0 (feat: add min-release-age-exclude config npm/cli#9532).

One important difference from pnpm/Yarn is that npm's exclude list matches package names or minimatch globs only (no pkg@version form supported). A bit of a pain and in all honestly probably means it's better not to add it for now.. raised https://github.com/orgs/community/discussions/204502 upstream!

(Note also that an entry that carries a version in the current implementation isn't actually rejected - it parses fine and matches nothing... so silently exempts nothing 😓)

Yarn: .yarnrc.yml

npmMinimalAgeGate: 7d
npmPreapprovedPackages:
  - "axios@1.18.1"

• npmPreapprovedPackages - added in 4.10.0 (feat: implement npmMinimalAgeGate and npmPreapprovedPackages config options yarnpkg/berry#6901).

Accepts full descriptors with semver ranges as well as name globs so should be able to use the same format as the exclusion entries Renovate already writes for pnpm?

---

Edit: fwiw I checked pnpm's behaviour (at 11.21.0) and it's slightly different to both Yarn/npm in that it applies the release window against the actual lockfile (meaning it does actually fail even for a pnpm install after a security fix if the exclusions are missing). So we're talking about slightly different motivations here for Yarn/npm, but ultimately requiring the same fix.

[MorrisonCole]

@RahulGautamSingh based on the npm difference there, let me know if you want this split into separate issues for Yarn (actionable now) and npm (probably best to wait)

[RahulGautamSingh]

Sure, you can split the yarn one and I'll create an issue for it. We can keep this discussion for npm (please update the title/description to reflect that) or if you wish you can also create a separate one for npm as well & close this one.

npm's approach sounds a bit too risky and I don't think we should be implementing support for that right now.

[MorrisonCole]

Sorry for the delay there @RahulGautamSingh - split out the Yarn one into #45279. Edited this one to be npm only.