Composer 'update-lockfile' does not respect in-range updates for ^1.2

[annuh]

What Renovate type, platform and version are you using?

Self-hosted (v24.12.3)

Describe the bug

Some of the dependencies in our composer.json file are using caret-style constraints (like ^3.0) to define allowed updates. So an update from v3.3.2 to v3.4.0 is 'in-range'.

We are using Renovate's '"rangeStrategy": "update-lockfile" option. For the example above (v3.4.0 -> v3.7.2) I expected that Renovate would only update the lockfile and not the composer.json as well.

According to the documentation: https://docs.renovatebot.com/configuration-options/#rangestrategy

update-lockfile = Update the lock file when in-range updates are available, otherwise replace for updates out of range. Works for bundler, composer, npm, and yarn, so far

However Renovate is creating PR's like this:

composer.json:
-        "doctrine/doctrine-fixtures-bundle": "^3.0",
+        "doctrine/doctrine-fixtures-bundle": "^3.4",

composer.lock:
-   "content-hash": "573ac5d6a30cfe5b8ed65853a53e6023",
+   "content-hash": "d2e4c065ca48a6736deec11067c13a99",
      "packages": {
            "name": "doctrine/doctrine-fixtures-bundle",
-            "version": "3.3.2",
+           "version": "3.4.0",

So Renovate updates composer.lock, which is expected, but is also updates composer.json, which is unexpected because the updated dependency is in-range of the defined constraint (^3.0).

Updating the composer.json also results in a new 'content-hash' in the composer.lock file which causes conflicts to the composer.lock file when merging multiple Renovate PR's.

Is it expected that caret-like constraints should be defined as strict as possible or is this indeed a bug in Renovate?

I hope this bug report is clear enough.

Relevant debug logs

# renovate.json

{
    "extends": [
        "config:base"
    ],
    "enabledManagers": [
        "composer",
    ],
    "rangeStrategy": "update-lockfile",
    "rebaseWhen": "conflicted"
}

Have you created a minimal reproduction repository?

https://github.com/annuh/renovate-issue-8250

• This is a really small bug, it does not need a reproduction (think small typo)
• I have provided a minimal reproduction repository
• I don't have time for that, but it happens in a public repository I have linked to
• I don't have time for that, and cannot share my private repository
• The nature of this bug means it's impossible to reproduce publicly

Additional context

^v1.2 vs ^v1.2.3
It seems this issue is caused because the dependency constraint is not 'strict' enough. Another update for v0.9.6 results in a PR with only an updated composer.lock file.

[viceice]

Please create a reproduction repo.

Please do not delete issue template sections.

[annuh]

Please create a reproduction repo.

You were fast 🙂 I've updated the bug report and created a reproduction repository: https://github.com/annuh/renovate-issue-8250

[rarkins]

It does seem to be specific to update-lockfile and "short" ranges (e.g. v5.1 but not v5.1.0). I checked against our composer versioning and it passes as expected:

[renovate-release]

🎉 This issue has been resolved in version 24.27.2 🎉

The release is available on:

• GitHub release
• 24.27.2

Your semantic-release bot 📦🚀