update --lock should not update packages

[obriat]

I ran composer update --lock in order to fix the "Warning: The lock file is not up to date with the latest changes in composer.json..." after removing a cweagans/composer-patchespatch in the composer.json.
I was expecting to only get a hash change in the composer.lock as said in the documentation.
But there were also minor changes :

• some authors updates
• a timestamp and version update in a drupal module ("type": "drupal-module" drupal/rest_entity_display:dev-2.0.x > extra > drupal > datestamp + version)
• an abandoned addition in php-http/guzzle6-adapter:v2.0.2
• funding addition, source > url & dist > url updates in squizlabs/php_codesniffer:3.7.2

If it's a normal behavior, maybe the doc (https://getcomposer.org/doc/03-cli.md#update-u-upgrade) should be updated. Adding a notice such as "expect also other minor changes on packages metadata) ?

Output of composer diagnose:

composer diagnose
Checking composer.json: WARNING
require.cloudflare/sdk : exact version constraints (1.1.6) should be avoided if the package follows semantic versioning
require.drupal/base_field_display : exact version constraints (1.0.x-dev@dev) should be avoided if the package follows semantic versioning
require.drupal/core-composer-scaffold : exact version constraints (9.5.11) should be avoided if the package follows semantic versioning
require.drupal/core-project-message : exact version constraints (9.5.11) should be avoided if the package follows semantic versioning
require.drupal/core-recommended : exact version constraints (9.5.11) should be avoided if the package follows semantic versioning
require.drupal/leaflet_mapbox : exact version constraints (1.0-alpha1) should be avoided if the package follows semantic versioning
require.drupal/leaflet_maptiler : exact version constraints (1.0-beta10) should be avoided if the package follows semantic versioning
require.drupal/office_hours : exact version constraints (1.11) should be avoided if the package follows semantic versioning
require.drupal/openapi_ui : exact version constraints (1.0-rc4) should be avoided if the package follows semantic versioning
require.drupal/openapi_ui_swagger : exact version constraints (1.0-rc4) should be avoided if the package follows semantic versioning
require.drupal/read_time : exact version constraints (2.x-dev@dev) should be avoided if the package follows semantic versioning
require.drupal/rest_entity_display : exact version constraints (2.0.x-dev@dev) should be avoided if the package follows semantic versioning
require.drupal/rest_views : exact version constraints (3.0.x-dev@dev) should be avoided if the package follows semantic versioning
require.drupal/search_api_location : unbound version constraints (@alpha) should be avoided
Checking platform settings: The xdebug extension is loaded, this can slow down Composer a little.
 Disabling it when using Composer is recommended.

Checking git settings: OK git version 2.30.2
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com rate limit: OK
Checking disk free space: OK
Checking pubkeys:
Tags Public Key Fingerprint: 57815BA2 7E54DC31 7ECC7CC5 573090D0  87719BA6 8F3BB723 4E5D42D0 84A14642
Dev Public Key Fingerprint: 4AC45767 E5EC2265 2F0C1167 CBBB8A2B  0C708369 153E328C AD90147D AFE50952
OK
Checking composer version: OK
Composer version: 2.6.6
PHP version: 8.1.16
PHP binary path: /usr/local/bin/php
OpenSSL version: OpenSSL 1.1.1n  15 Mar 2022
cURL version: 7.74.0 libz 1.2.11 ssl OpenSSL/1.1.1n
zip: extension present, unzip present, 7-Zip not available

[Seldaek]

Turns out the update --help output was correct already, just the docs were not synced, fixed that.

[hostep]

@Seldaek: We still have an issue (started happening after composer 2.0.0 I seem to remember) that running composer update --lock updates the url and shasum unexpectedly for packages with a constraint that start with dev- and thus reference a branch. It updates the values in url and shasum to the latest version of that branch instead of re-using the current values (which it should do, since the packages didn't get updated).

I've tried to find steps to reproduce in the past 2 years to try to report the issue here, but never managed to and then just gave up, I think it's related to our custom private Satis repository (which is running a pretty outdated version, we still need to support composer v1 functionality unfortunately). I can never reproduce it with packages that come from packagist.org.

I can still reproduce it today with composer version 2.6.6

I have the suspicion that this action wasn't taken yet, but I'm not sure, that's just guessing: #9812 (comment)

Sorry for intruding here in this issue, maybe I should create a new one instead?

[Seldaek]

@hostep you're right, 042a8c2 should hopefully take care of it.. doing this in 2.7-dev tho as I'd rather not mess with this stuff in a patch release.

[hostep]

Awesome, thanks!

[hostep]

Hi @Seldaek

I can confirm that with composer 2.7.0/2.7.1 this is mostly fixed. But not 100% yet.

I notice that if the latest version of a package with dev-{branch} constraint has updated requirements, that running composer update --lock still updates those requirements in the lock file, which is a bit confusing.

I'm for example now seeing this diff in the composer.lock after running composer update --lock even though we didn't update the dependency itself yet:

                 "magento/module-store": "^101.0.0",
                 "magento/module-tax": "^100.3.0",
                 "magento/module-tax-import-export": "^100.3.0",
-                "php": "~7.2.0 || ~7.3.0 || ~7.4.0 || ~8.1.0 || ~8.2.0"
+                "php": "~7.2.0 || ~7.3.0 || ~7.4.0 || ~8.1.0 || ~8.2.0 || ~8.3.0"
             },
             "type": "magento2-component",
             "autoload": {

Would it be technically possible to also not update these fields when a dev-dependency isn't getting updated?

[drupol]

Dear @hostep, @obriat,

Can you provide the simplest composer.json and composer.lock along with the procedure to reproduce the issue ?

[hostep]

Sorry I can not, it only triggers with packages from our private Satis composer repository.

[Seldaek]

The last commit here efa03f9 in #11850 should hopefully address this @hostep.

[Seldaek]

@hostep ok you can now composer self-update --snapshot if you wanna try it.

[hostep]

@Seldaek: just tested it with the latest snapshot (66acb84) and can confirm it's working perfectly as expected. Thank you and @drupol very much!

[drupol]

@Seldaek did all the job, props to him as well !