NPM dependencies seem to not respect minimumReleaseAge

[DanStough]

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?

42.59.0"

Please tell us more about your question or problem

For NPM dependencies, we are seeing Pull Requests created by Renovate that don't seem to respect the minimumReleaseAge setting in our config file. In the log section, there is an example of one of these dependencies, sass. You can see that the new version has a newVersionAgeInDays less than the minmum age we have set, "7".

I've created a minimal repro here that matches the structure of our monorepo. I use the same problematic dependency, but with a longer 14-day window. You can see renovate still generates an update PR here.

I reviewed the discussion board, and #39963 seemed similar, but not even using ignorePresets or totally overriding minimumReleaseAge in packageRules seems to work.

Thank you in advance!

Logs (if relevant)

Logs

          {
            "currentValue": "1.96.0",
            "currentVersion": "1.96.0",
            "currentVersionAgeInDays": 8,
            "currentVersionTimestamp": "2025-12-11T00:17:14.898Z",
            "datasource": "npm",
            "depName": "sass",
            "depType": "devDependencies",
            "fixedVersion": "1.96.0",
            "isAbandoned": false,
            "isSingleVersion": true,
            "lockedVersion": "1.96.0",
            "mostRecentTimestamp": "2025-12-16T06:38:40.003Z",
            "packageName": "sass",
            "prettyDepType": "devDependency",
            "registryUrl": "https://registry.npmjs.org",
            "sourceUrl": "https://github.com/sass/dart-sass",
            "versioning": "npm",
            "warnings": [],
            "updates": [
              {
                "bucket": "non-major",
                "newVersion": "1.97.0",
                "newValue": "1.97.0",
                "releaseTimestamp": "2025-12-16T06:38:40.003Z",
                "newVersionAgeInDays": 3,
                "newMajor": 1,
                "newMinor": 97,
                "newPatch": 0,
                "updateType": "minor",
                "isBreaking": false,
                "libYears": 0.014424312056062913,
                "branchName": "renovate/sass-1.x"
              }

[jamietanna]

@RahulGautamSingh are you able to take a look, please?

All debug logs for Job ID 049dc9ec-e756-4f02-82ec-0625b1f9854f which created the PR: https://gist.github.com/jamietanna/e5d9cd47c5624560c289cdf295ddf97d

[RahulGautamSingh]

On first look, I wonder if it's related to the current version being younger than the minimum release age limit as well (maybe hitting some edge case during comparison, need to take a better look to be sure).

Will look deeper, thanks for creating the discussion @DanStough

[cvoege]

I don't believe it has anything to do with the current version being younger than the minimum release age. If that were the case all our builds would fail since pnpm errors if you try to install something inside the minimum release age specified in pnpm-workspace.yaml. The current versions in our app pass the release age requirement, it's the new versions renovate tries to install that have issues.

[cvoege]

Is there any update here @jamietanna @RahulGautamSingh ? We're still dealing with renovate being basically useless on our pnpm project because it just suggested versions that are too new every day.

[cvoege]

Ah, just after posted that I was able to repro! It required setting up a very complex package.json similar to the one we use in our actual repo to reproduce the issue:

https://github.com/cvoege/renovate-repro/pulls

Here is a specific PR that fails while trying to update multiple deps: cvoege/renovate-repro#11

And here is one that fails while trying to install a single dependency: cvoege/renovate-repro#10

Thank you again for the help!

[RahulGautamSingh]

Seems concerning! I will try to debug locally tomorrow to find the root cause. If I miss updating here, feel free to ping.

[cvoege]

Thanks Rahul! I can confirm that this is still happening, it recreated both of those PRs today in our repo.

[RahulGautamSingh]

Cause

The issue is package rule ordering and override precedence.

security:minimumReleaseAgeNpm (from config:best-practices) injects this package rule:

  {
    internalChecksFilter: 'strict',
    matchDatasources: ['npm'],
    minimumReleaseAge: '3 days',   // ← overrides your global "7 days"
  }

Package rules from extended presets are applied before your repo's own package rules. Your top-level minimumReleaseAge: "7 days" is the base config, but the preset's package rule runs after it and overwrites the value for npm packages to 3 days.

Since none of your own packageRules match @tanstack/* to override it back, the tanstack packages end up with minimumReleaseAge: "3 days".

Fix

Add an npm-scoped package rule to your packageRules that explicitly sets your desired value. Since your rules are processed after preset rules, this wins:

  {
    "description": "Override npm minimum release age to 7 days (security:minimumReleaseAgeNpm defaults to 3)",
    "matchDatasources": ["npm"],
    "minimumReleaseAge": "7 days",
    "internalChecksFilter": "strict"
  }

Place it at the beginning of your packageRules array

[cvoege]

It seems like this worked, I'll follow up if there's any more issues from our end!

[cvoege]

Do you think this is perhaps a pattern that should be changed in renovate? The best practices config injecting a package rule that overrides top level rules like minimumReleaseAge feels like a natural source for confusion.

[RahulGautamSingh]

I'll need to give it more thought. extends or presets are expected to contain pkg rules which are more granular and are applied at pkg level ..hence override the top level rules.

I think users should check before including presets, what they are getting from the presets, we will also try and see if we can make rules like minimumReleaseAge more visible

[cvoege]

Yeah I see the thorny sides of it. I'll leave that to you, thanks again!

[github-actions[bot]]

Hi there,

This is intended as a polite, automated request that users avoid @ mentioning repository maintainers like @viceice. Doing so causes annoying mobile notifications and makes it harder to maintain this repository.

We know it might be common elsewhere but we participate in hundreds of discussions a week and would need to turn off GitHub mobile notifications if we were mentioned in every one.

As a general rule, we will read and respond to all discussions in this repository, so there is no need to mention us.

Thanks, the Renovate team

[RahulGautamSingh]

@DanStough This reply is delayed, but the issue in your case might be the use of ignorePresets to remove security:minimumReleaseAgeNpm