Why composer normalize do an update command?

[soullivaneuh]

$ composer normalize
Successfully normalized ./composer.json.
                                                                                 
What about running composer global require symfony/thanks && composer thanks now?ocramius/package-versions:  Generating version class...
ocramius/package-versions: ...done generating version class

This will spread some 💖  by sending a ★  to the GitHub repositories of your fellow package maintainers.

Executing script cache:clear [OK]
Executing script cache:warmup [OK]
Executing script assets:install --symlink --relative public [OK]
Executing script security-checker security:check [OK]

> chmod +x vendor/cpliakas/git-wrapper/bin/git-ssh-wrapper.sh
No changelogs summary
8 packages are not up to date:

  - javiereguiluz/easyadmin-bundle (v1.17.8) latest is v1.17.9

  - jeremykendall/php-domain-parser (4.0.3-alpha) latest is 5.1.0

  - league/uri (4.2.3) latest is 5.2.0

  - michelf/php-markdown (1.7.0) latest is 1.8.0

  - ocramius/proxy-manager (2.1.1) latest is 2.2.0

  - symfony/options-resolver (v3.4.3) latest is v4.0.3

  - symfony/serializer (v3.4.3) latest is v4.0.3

  - symfony/yaml (v3.4.3) latest is v4.0.3

I don't get it. It would maybe make sense to run composer validate, but why composer update?

[soullivaneuh]

update the hash in composer.lock if it exists and if an update is necessary

Next time I will read the doc carefully. 😅

[localheinz]

@soullivaneuh

I wasn’t sure myself whether I should update composer.lock (if it exists) myself or emit a warning, suggesting that it might be necessary to run

$ composer update —lock

As you can see in https://github.com/localheinz/composer-normalize/blob/0.1.0/src/Command/NormalizeCommand.php#L126-L132, I am trying to update the lock file. Unfortunately, it seems that the —no-plugins option is ignored, further slowing down the operation.

Ideally, I would like to be able to update the hash directly (by using one of composer’s components. Alternatively, which I think is worth suggesting, the calculation of the hash itself could normalize corresponding fields prior to calculation - after all, the order doesn’t exactly matter (except for composer/composer#6840).

What do you think?

Maybe I should remove the update step.

[soullivaneuh]

after all, the order doesn’t exactly matter

Well, your plugin just change the format, not the requirement, so it should not be.

But if I do a composer validate after moving dependencies order, it's indeed yelling:

sullivan@e1c58ce7e5ba:/code$ composer validate
./composer.json is valid
The lock file is not up to date with the latest changes in composer.json, it is recommended that you run `composer update`.

Ideally, I would like to be able to update the hash directl

Can't you? At least,

it seems that the —no-plugins option is ignored

I'm not sure why. Maybe because it's global plugins? BTW, you should also add the --no-scripts option IMO.

[soullivaneuh]

We also might have another issue if we want to run this on a CI tool. When VCS repositories are setup, composer make multiple GitHub API call.

It can prompt for an oauth token and then the CI will break. 😕

[localheinz]

@soullivaneuh

How about specifying a GitHub token, similar to how we do it for Travis CI in .travis.yml, or adding an option that skips updating the locker, e.g. --no-update-lock?