fix(composer): resolve the lockFileMaintenance not working

[kayw-geek]

Changes

Fixed an issue where the lockFileMaintenance configuration was not working for the Composer manager.
Currently, triggering LockFileMaintenance via webhook does not perform any actions.

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[rarkins]

Do you have a reproduction repo to demonstrate this before/after?

[kayw-geek]

Hi @rarkins
https://github.com/kayw-geek/24958
This repository can reproduce the current behavior of the Composer manager.
The expected behavior is that composer’s lockFileMaintenance should execute composer update, after which the composer.lock file should change, and the version of guzzlehttp/guzzle should update from 7.9.0 to the latest 7.9.2.

[viceice]

usally both ways should work. most managers are using the updateType

renovate/lib/workers/repository/updates/flatten.ts

Lines 150 to 151 in dc7b8d9

	lockFileConfig.updateType = 'lockFileMaintenance';
	lockFileConfig.isLockFileMaintenance = true;

@rarkins should we check all managers to be consistent?

[viceice]

maybe related to the grouping?
https://github.com/kayw-geek/24958/blob/6a7804b2030da6dcdc53bb71f39aa31378bfa2a5/renovate.json#L17

[kayw-geek]

maybe related to the grouping? https://github.com/kayw-geek/24958/blob/6a7804b2030da6dcdc53bb71f39aa31378bfa2a5/renovate.json#L17

Should I delete this groupName?

[rarkins]

@rarkins should we check all managers to be consistent?

Yes, I suspect there may be some inconsistency here. And we should pay attention to the case where people group lock file maintenance with regular updates. It's not something which we recommend, and it will have different behavior per manager, but many people do it

[viceice]

@rarkins should we check all managers to be consistent?

Yes, I suspect there may be some inconsistency here. And we should pay attention to the case where people group lock file maintenance with regular updates. It's not something which we recommend, and it will have different behavior per manager, but many people do it

We should issue a warning if lockfile maintenance is grouped with other updates, so users are aware that it's not always working as intended.

I think i know why it's not working here:
First update is a regular update, so isLockFileMaintenance is not copied to branch config, but somehow the updateType is copied. 🤔

[kayw-geek]

Hi @rarkins @viceice ,

Just wanted to check if there’s any update on the PR, Please let me know if you need anything from my side to move it forward.

[kayw-geek]

hi @rarkins @viceice,
I would like to confirm if this is a more appropriate approach for Composer update command.

Currently, we use the composer update packageName:packageVersion format to update dependencies. However, if a package version is locked in composer.json (e.g., foo:1.0.0), when Renovate detects version 1.1.0, it attempts to execute the following command to upgrade: composer update foo:1.0.0 --with-dependencies. In reality, this command will fail and produce the following error:

The temporary constraint "1.1.0" for "foo" must be a subset of the constraint in your composer.json (1.0.0)
Run `composer require foo` or `composer require foo:1.1.0` instead to replace the constraint

This situation may also happen when updating the major version.

If my conclusion is correct, should we update the logic to use composer require instead, and depending on the depType, decide whether to add the --dev flag?

Alternatively, should we consider modifying the version constraint in composer.json before running the update command to avoid this issue altogether?

[viceice]

hi @rarkins @viceice,
I would like to confirm if this is a more appropriate approach for Composer update command.

Currently, we use the composer update packageName:packageVersion format to update dependencies. However, if a package version is locked in composer.json (e.g., foo:1.0.0), when Renovate detects version 1.1.0, it attempts to execute the following command to upgrade: composer update foo:1.0.0 --with-dependencies. In reality, this command will fail and produce the following error:

The temporary constraint "1.1.0" for "foo" must be a subset of the constraint in your composer.json (1.0.0)
Run `composer require foo` or `composer require foo:1.1.0` instead to replace the constraint

This situation may also happen when updating the major version.

If my conclusion is correct, should we update the logic to use composer require instead, and depending on the depType, decide whether to add the --dev flag?

Alternatively, should we consider modifying the version constraint in composer.json before running the update command to avoid this issue altogether?

this seems to be a change in recent composer versions, can you pinpoint the version which breaks renovate?

I think we can change the composer.json before running composer, like we do for other managers.

[viceice]

see other comment.

[kayw-geek]

see other comment.

The feature introduces seems like on this commit