How do the package rules actually work in matching packages (for NPM)?

[shan-du]

How are you running Renovate?

Self-hosted

If you're self-hosting Renovate, tell us what version of Renovate you run.

36.57

If you're self-hosting Renovate, select which platform you are using.

gitlab.com

Was this something which used to work for you, and then stopped?

I never saw this working

Wanted end result.

I have a few NPM repos on react, and I wish to have upgrades from mono-repos grouped together, but ALL other individual package upgrades separated into single PRs, for both dependencies AND devDependencies, but NOT peerDependencies.

so the correct end results would be something like this:

PR1: Upgrade babel monorepo
PR2: Upgrade material-ui monorepo
PR3: ... etc.
PR10: Upgrade nodemon ^2.0.12 -> ^2.0.22 
PR11: Upgrade axios ^2.25.0 -> ^2.30.0
PR12: ... etc.

However, I can not seem to get this working, and the more things I try, the more confused I get about the package rules.

What you tried so far.

General Questions I have are

1. If there are multiple package rules having overlapping effects, which one takes precedence?
2. Follow up on Q1, if there IS a rule priority order, would the rules with lower priority gets completely ignored?
   • for example: rule1 matches package 1, 2, 3, rule2 matches package 3, 4, 5, but rule1 somehow ranks higher than rule2, would rule2 never carries out, hence package 4 & 5 NEVER get matched at all?
3. The branches created by for the PR, if they are not deleted, do they affect future PR generation?

What we have tried

So far this is the only config that captures ALL upgrades correctly, but it groups things into 2 PRs only, so it's not the grouping strategy we want

{
  "extends": ["config:recommended", ":disableMajorUpdates"],
  "ignoreDeps": ["private-repos"],
  "rangeStrategy": "bump",
  ...
  "packageRules": [
    { "matchDepTypes": ["peerDependencies"], "enabled": false },
    {
      "matchDepTypes": ["devDependencies"],
      "groupName": "devDependencies",
      "rangeStrategy": "bump"
    },
    {
      "matchDepTypes": ["dependencies"],
      "groupName": "dependencies",
      "rangeStrategy": "bump"
    }
  ],
  "prConcurrentLimit": 0,
  "prHourlyLimit": 0,
  ...
}

---

This ONLY generates PRs on the mono repos but nothing else

{
  "extends": ["group:monorepos", ":disableMajorUpdates"],
  "ignoreDeps": ["private-repos"],
  "rangeStrategy": "bump",
  ...
  "packageRules": [
    { "matchDepTypes": ["peerDependencies"], "enabled": false }
  ],
  "prConcurrentLimit": 0,
  "prHourlyLimit": 0,
  ...
}

---

This just doesn't produce any PRs for some reason, is this rule { "matchPackagePatterns": ["*"], "groupName": null } completely ignored???

{
  "extends": ["group:monorepos", ":disableMajorUpdates"],
  "ignoreDeps": ["private-repos"],
  "rangeStrategy": "bump",
  ...
  "packageRules": [
    { "matchDepTypes": ["peerDependencies"], "enabled": false }
    { "matchPackagePatterns": ["*"], "groupName": null }
  ],
  "prConcurrentLimit": 0,
  "prHourlyLimit": 0,
}

---

Manually grouping mono repos without using presets, this also does NOT create PRs for any other individual packages

{
  "extends": [":disableMajorUpdates"],
  "ignoreDeps": ["private-repos"],
  "rangeStrategy": "bump",
  ...
  "packageRules": [
    { "matchDepTypes": ["peerDependencies"], "enabled": false }
    {
      "extends": "monorepo:babel",
      "groupName": "babel monorepo"
    },
    {
      "extends": "monorepo:date-io",
      "groupName": "date-io monorepo"
    },
    {
      "extends": "monorepo:emotion",
      "groupName": "emotion monorepo"
    },
    {
      "extends": "monorepo:jest",
      "groupName": "jest monorepo"
    },
    {
      "extends": "monorepo:material-ui",
      "groupName": "mui monorepo"
    },
    {
      "extends": "monorepo:react",
      "groupName": "react monorepo"
    },
    {
      "extends": "monorepo:react-router",
      "groupName": "react-router monorepo"
    },
    {
      "extends": "monorepo:storybook",
      "groupName": "storybook monorepo"
    },
    ...etc.
  ],
  "prConcurrentLimit": 0,
  "prHourlyLimit": 0,
}

---

The most basic one, this again, produces NO PRs

{
  "extends": [":disableMajorUpdates"],
  "ignoreDeps": ["private-repos"],
  "rangeStrategy": "bump",
  ...
  "packageRules": [
    { "matchDepTypes": ["peerDependencies"], "enabled": false }
  ],
  "prConcurrentLimit": 0,
  "prHourlyLimit": 0,
  ...
}

---

Manually grouping packages based on what our repo has, this again, ONLY produces PRs for the defined groups, but nothing else.
Adding { "matchPackagePatterns": ["*"] } rule does not have any effects

{
  "extends": ["config:recommended", ":disableMajorUpdates"],
  "ignoreDeps": ["private-repos"],
  "rangeStrategy": "bump",
  ...
  "packageRules": [
    { "matchDepTypes": ["peerDependencies"], "enabled": false },
{
      "matchPackagePrefixes": ["@mui"],
      "groupName": "MUI"
    },
    {
      "matchPackagePrefixes": ["@emotion"],
      "groupName": "Emotion"
    },
    {
      "matchPackagePrefixes": ["react"],
      "groupName": "React"
    },
    {
      "matchPackagePrefixes": ["eslint"],
      "groupName": "ESLint"
    },
    ...etc.
  ],
  "prConcurrentLimit": 0,
  "prHourlyLimit": 0,
  ...
}

Relevant debug logs

Logs

Copy/paste the relevant log(s) here, between the starting and ending backticks

[secustor]

All PackageRules are getting individually, serially and in the order in which they are defined evaluated.
If multiple rules match and set the same config option e.g. groupName the last one wins as the later rules overwrite the result from the earlier ones.

Renovate always tries to reach the desired state, therefore branches are getting deleted and PRs closed.

So what you want should be this:

{
  "extends": ["config:recommended", ":disableMajorUpdates"],
  "ignoreDeps": ["private-repos"],
  "rangeStrategy": "bump",
  "packageRules": [
    { "matchDepTypes": ["peerDependencies"], "enabled": false },
    {
      "matchDepTypes": ["devDependencies"],
      "groupName": "devDependencies",
      "rangeStrategy": "bump"
    },
    {
      "matchDepTypes": ["dependencies"],
      "groupName": "dependencies",
      "rangeStrategy": "bump"
    },
{
      "matchPackagePrefixes": ["@mui"],
      "groupName": "MUI"
    },
    {
      "matchPackagePrefixes": ["@emotion"],
      "groupName": "Emotion"
    },
    {
      "matchPackagePrefixes": ["react"],
      "groupName": "React"
    },
    {
      "matchPackagePrefixes": ["eslint"],
      "groupName": "ESLint"
    },
    "...":"..."
  ],
  "prConcurrentLimit": 0,
  "prHourlyLimit": 0
}

If not, create a reproduction repo.

[shan-du]

But we do have the rules to uncap those limits...

  "prConcurrentLimit": 0,
  "prHourlyLimit": 0,

is there an absolute hard-limit set by Renovate that we can not overwrite? if so, what are the values? I couldn't find this in any docs :(

[rarkins]

Here's what you need to do:

• Focus on one particular dependency
• Locate it in the packageFiles with updates log message
• Check what branch name it has
• Look in the (debug) logs for mentions of that branch name

[shan-du]

Hi there, thank you so much for all your help, I think I've finally realized the issue is potentially in our setup, because I started to test & run Renovate on those reproduction repos I setup on Github, and guess what? They are producing the right results!! But running the same config on our own repos don't!!

So we'll try to investigate on our end & see what's going on there. I am sorry that I've kinda wasted your time on this! 🙏 🙏 and thank you again for taking the time & effort! 🙌 🙌

[shan-du]

OK I found out what's wrong, turns out it was this config recreateWhen

By default it's set to "auto", and for some reason, that seems to make Renovate "randomly" reopen some closed MRs but not others, and the odd things is that different MRs are re-opened each time, this was the root for all the inconsistency & confusions we are getting, is this an actual bug in Renovate?

Either way, when setting it to "recreateWhen": "always", PRs are now (re)created consistently & correctly

[rarkins]

It may seem random, but such things are never random. If you're interested in troubleshooting it, focus on one branch's logs

[github-actions[bot]]

Hi there,

Get your issue fixed faster by creating a minimal reproduction. This means a repository dedicated to reproducing this issue with the minimal dependencies and config possible.

Before we start working on your issue we need to know exactly what's causing the current behavior. A minimal reproduction helps us with this.

To get started, please read our guide on creating a minimal reproduction.

We may close the issue if you, or someone else, haven't created a minimal reproduction within two weeks. If you need more time, or are stuck, please ask for help or more time in a comment.

Good luck,

The Renovate team