commitMessageExtra + matchDepTypes not applied when there are 2 types of updates for the same dep

[NiGhTTraX]

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?

43.102.11

Please tell us more about your question or problem

Tip

While writing this I've realized how to achieve what I wanted by using "matchUpdateTypes": ["major"] instead of "matchDepTypes": ["peerDependencies"], but I've decided to create this issue nonetheless, because I find the behavior confusing.

renovate.json

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended"
  ],
  "semanticCommits": "enabled",
  "separateMajorMinor": true,
  "packageRules": [
    {
      "matchPackageNames": ["typescript"],
      "matchDepTypes": ["peerDependencies"],
      "commitMessageAction": "Support",
      "commitMessageTopic": "{{depName}}",
      "commitMessageExtra": "{{prettyNewMajor}}",
      "semanticCommitType": "feat",
      "semanticCommitScope": null,
      "commitMessageLowerCase": "never"
    }
  ]
}

package.json

{
  "peerDependencies": {
    "typescript": "^5"
  },
  "devDependencies": {
    "typescript": "~5.0.4"
  }
}

Outcome

Expected: feat: Support typescript v6
Actual: feat: Support typescript to v6.0.2

Notes

The same commit that widens the peer dependencies, also updates the dev dependencies, as expected 👍

Unfortunately, that seems to somehow result in JUST the commitMessageExtra not applying — every other part of the config is respected AFAICT.

If I replace matchDepTypes with matchUpdateTypes: ['major'] then I get the expected result. I'm guessing that with the former there are 2 updates battling it out for the commit message, but it's confusing why the rest of the message parts are applied correctly, e.g. commitMessageAction and semanticCommitScope.

With matchUpdateTypes (correct)	With matchDepTypes (incorrect)

Logs (if relevant)

I don't see any granular logs about applying the packageRules or computing the commit messages.

[itxashancode]

I think the issue is that matchDepTypes applies to the dependency type, but when Renovate sees both peer and dev deps for the same package, it merges them into a single update and the commitMessageExtra rule only fires for the primary update type. With matchUpdateTypes: ["major"] it works because the rule applies to the update kind instead of the dependency type.

Try switching to matchDepTypes: ["peerDependencies", "devDependencies"] - that should make the rule apply to both updates and include the extra text. Or use matchUpdateTypes: ["major"] if you want it for all major bumps regardless of dep type.

If you still only get one update, check the logs for "group" behavior - Renovate may be collapsing them. In that case, matchPackageNames alone without matchDepTypes should catch both.

[NiGhTTraX]

and the commitMessageExtra rule only fires for the primary update type

But the rest of the config, like commitMessageAction and semanticCommitScope, is applied correctly (see the last screenshot). It's only commitMessageExtra that's not applied.

[itxashancode]

You're right, that was a bad explanation on my part, thanks for the correction.

The real issue is likely in how commitMessageExtra is computed. commitMessageAction, commitMessageTopic, and semanticCommitScope are all static strings or simple templates ({{depName}}), so they resolve the same regardless of which dep type "wins". But commitMessageExtra uses {{prettyNewMajor}}, which depends on the version being resolved, and when the rule matches via matchDepTypes: ["peerDependencies"], Renovate is pulling the version from the peer dep update (^5 → ^6), while the merged commit message is being assembled from the dev dep update (~5.0.4 → 6.0.2).

So you end up with the template from the peer dep rule, but the version interpolation from the dev dep, and prettyNewMajor falls back to the dev dep's raw version string 6.0.2 instead of rendering as v6.

Using matchUpdateTypes: ["major"] sidesteps this entirely because the rule matches the merged update directly, so the version context is consistent throughout.

[NiGhTTraX]

That's a good guess, but unfortunately it seems more nuanced than that. I added {{prettyNewMajor}} inside the commitMessageAction template as well and it resulted in this message:

feat: Support v6 typescript to v6.0.2

So commitMessageAction is being applied correctly from the rule that matches the peer dep upgrade, but commitMessageExtra is not 😖

Config:

  "packageRules": [
    {
      "matchPackageNames": ["typescript"],
      "matchDepTypes": ["peerDependencies"],
      "commitMessageAction": "Support {{prettyNewMajor}}",
      "commitMessageTopic": "{{depName}}",
      "commitMessageExtra": "{{prettyNewMajor}}",
      "semanticCommitType": "feat",
      "semanticCommitScope": null,
      "commitMessageLowerCase": "never"
    }
  ]

---

P.S.: I know matchUpdateTypes: ["major"] solves this, but I'm itching to get to the bottom of this confusing behaviour 😄

[itxashancode]

That's a really useful data point, it rules out the version context theory entirely.

Since {{prettyNewMajor}} resolves correctly in commitMessageAction but not in commitMessageExtra, the issue is almost certainly in how Renovate assembles the final commit message when multiple dep types are merged into one update. My best guess now:

commitMessageExtra is likely being sourced from the dev dependency update (which has a concrete version 5.0.4 → 6.0.2), while commitMessageAction is being sourced from the peer dependency update (which is the one matched by your rule). In other words, Renovate may be mixing fields from two different update objects when it merges them, taking some fields from the peer dep match and others (specifically commitMessageExtra) from the dev dep's default template.

The reason commitMessageExtra specifically is affected could be that it's evaluated at a different point in the merge pipeline, or that the default for dev dep updates (to {{newVersion}}) is overriding your custom value after the rule is applied.

This honestly looks like a Renovate bug rather than a config issue. It's worth opening a bug report and including your test case — the reproduction is clean and the behavior is clearly inconsistent. The matchUpdateTypes: ["major"] workaround confirms the expected output is achievable, which makes it easier for maintainers to pinpoint the regression.