minimumReleaseAge is not working with lockFileMaintenance and transitive Dependencies

[onigoetz]

Tell us more.

Hello,

I realized that minimumReleaseAge will only work for direct dependencies and for actions performed by Renovate. Not for any action handled by package Managers

case 1: lockFileMaintenance

LockFileMaintenance will delete the lockFile and ask the package manager to generate a new one.
Unless the package manager also has a minimumReleaseAge it will choose the latest version. Potentially younger than minimumReleaseAge.

case 2: transitive dependencies introduced by updates

Let's say I have a package at version 1.0.0. Renovate creates a Pull Request to update to version 1.0.1 (properly respecting minimumReleaseAge)
This new dependency introduces a new transitive dependency with a range of version: the latest version of that dependency was released hours ago and has a vulnerability
Unless the package manager also has a minimumReleaseAge it will choose the latest version (that is vulnerable).

Mitigations

pnpm 10.16 and yarn 4.10.0 both introduced options similar to minimumReleaseAge but they aren't set by default.

It would be useful that Renovate sets environment variables to set the package manager's configuration to align it with minimumReleaseAge if set.

[Chippiewill]

It would be handy to support this in other languages too, uv supports it for Python lockfiles: https://docs.astral.sh/uv/reference/settings/#exclude-newer

[jamietanna]

It would be useful that Renovate sets environment variables to set the package manager's configuration to align it with minimumReleaseAge if set.

Do you have a link to which environment variables would need to be set by Renovate when calling pnpm and yarn to ensure that they're aware we want to follow minimumReleaseAge?

[onigoetz]

Yarn

For yarn the setting is https://yarnpkg.com/configuration/yarnrc#npmMinimalAgeGate
if I get the env var documentation correctly it should be YARN_NPM_MINIMAL_AGE_GATE

The value is in minutes.

pnpm

The documentation asks for a value in minutes. https://pnpm.io/settings#minimumreleaseage

However I can't figure out how the value should be named in an environment variable.
from reading other config pages https://pnpm.io/pnpm-cli#environment-variables it seems it's not possible

[jamietanna]

pnpm/pnpm#9921 (comment) indicates that for pnpm we can at least specify the CLI flag

[jamietanna]

We may also be able to use npm's --before via @philippe-granet

[Hongwei-W]

I also agreed that the indirect dependencies, especially lockFileMaintenance, should also be regulated by the minimumReleaseAge.

For example, in Python, most packages do not set an upper bound for their dependencies. Therefore, during the lockFileMaintenance of the pip-compile manager, all indirect dependencies will be refreshed to the latest released version if the direct dependencies support them or do not explicitly define an upper bound. This defeats the purpose of having the minimumReleaseAge.

Just giving an idea of how I enforce that with pip-compile manager.

• I used a constraints.txt file and used it when in pip-compile (i.e. pip-compile -c constraints.txt requirements.in).
  • This constraints.txt file contains all the indirect dependencies listed in the requirements.txt, but with <= notation instead of pinning a specific version with ==.
  • This constraints.txt is not a list of indirect dependencies we are using; it just defines "if we want to use a package, how high the version can be".
• I then define a Renovate rule to upgrade this constraints.txt with minimumReleaseAge and not separateMajorMinor.
  • Thus, whatever is in the constraints.txt can be upgraded with a minimumReleaseAge.
  • The PR can be auto-merge because it does not introduce anything into the repo.
• During lockFileMaintenance of pip-compile manager (Renovate essentially deletes the requirements.txt file and regenerates one with pip-compile), Renovate calls pip-compile to regenerate lockfile/indirect dependencies' versions with constraints.txt, where the highest version of the indirect dependencies does not exceed what was defined in the constraints.txt, which Renovate in turn regulates.

However, the drawback of this solution is the manual effort required to maintain the constraints.txt file.

I hope Renovate can develop a built-in solution that applies the minimumReleaseAge not only to direct dependencies but also to indirect ones.

[augi]

Maybe it would make more sense to have a mechanism directly in the Python tooling 🤔

[Hongwei-W]

I am not sure if there is one now?

The only other ones I feel can do the similar is uv's exclude_newer, but this timestamp string needs to be manually edit plus Renovate does not support uv.

[philippe-granet]

https://docs.pypi.org/api/index-api/
Pypi Json Api have a "upload-time" attribute for each dependencies versions

[jamietanna]

The epic tracking this is #41652 - when we have clear indications of package managers that can be passed these constraints via CLI/environment variables, we'll share this information to enforce it

[dontgitit]

We hit a related issue: when minimumReleaseAge is set at the top level, lockFileMaintenance inherits it but the renovate/stability-days status check stays pending forever.

Root cause: For lockFileMaintenance PRs, Renovate creates virtual "upgrade" entries (one per package.json file) with updateType: lockFileMaintenance but no releaseTimestamp. With the default minimumReleaseAgeBehaviour: timestamp-required, any upgrade without a timestamp causes the stability check to fail.

Workaround: Set minimumReleaseAgeBehaviour: timestamp-optional for lockFileMaintenance:

"lockFileMaintenance": {
  "minimumReleaseAgeBehaviour": "timestamp-optional"
}

Suggestion: Should lockFileMaintenance default to one of these?

• minimumReleaseAge: null (disable inheritance)
• minimumReleaseAgeBehaviour: timestamp-optional
• statusCheckNames: { minimumReleaseAge: null }

The current default seems like it will always break for anyone using both features, until #41652 is implemented.

[jamietanna]

If you see security:minimumReleaseAgeNpm this is how we set it for the npm datasource+manager, and it's how we'd recommend setting it for lockFileMaintenance

(Note that it does default to minimumReleaseAge: null but your top-level config overrides it)

[dontgitit]

ah, didn't notice that preset before, thanks! sounds like i should use it along with a packageRule

    {
      "description": "Override preset's 3-day minimum to match pnpm-workspace.yaml",
      "matchDatasources": ["npm"],
      "minimumReleaseAge": "7 days"
    }

to reset the minimumReleaseAge for regular npm updates to match my top-level config / my pnpm's minimumReleaseAge.

[dontgitit]

P.S. that seemed to also re-enable minimumReleaseAge for lockFileMaintenance, so I need an additional rule to null is back out... at this point going to just use minimumReleaseAge: null without the preset