composer: Packages don't update to latest commit / Package repo fails to update

Bringing this issue up, because this truly rustles my jimmies. I accept that Composer will never work like you’d hope it work; e.g. dev-master always checking the actual master and then checking out the latest commit.

But when you have a package at packagist.org, which is autoupdated when a commit is pushed into the package repository, and you can see the commit hash change, it’s infuriating to see Composer report with “Nothing to install or update” when running composer update.

This is a massive UX problem, and causes hate against Composer because it’s unintuitive when you compare it to other package managers such as npm. 5 out of 5 people that I’ve introduced to Composer hate it because of reasons like this. I’m not kidding. It’s pretty hard to get them to adopt it after they hate it.

The problem could be easily mitigated by extending the response of composer update. Simply tell users what to actually do (add commit hash to the constraint) if they’re using dev-*, instead of making them search for an answer. I’ve used Composer for quite a while and I still stumble upon this issue every now and then.

The other issue that I’d like to mention; Getting a minimum stability error when trying to install a package is infuriating, as it doesn’t even tell you what to do. Instead you’re meant to read the docs and google the error message with correct keywords to get a solution. You can rinse and repeat this for just about any error 😂

Not sure if this is still relevant, but I am able to reproduce this issue right now using latest Composer version.

It sees 84093d0 as the latest commit for some reason, while it should be 009de30 as it’s the HEAD. It works if I pass the commit hash explicitly but this is not ideal.

Also if I run it without the hash afterwards it actually downgrades it back to 84093d0 🙂

~/.wp-cli/packages # composer --version
Composer version 2.3.10 2022-07-13 15:48:23

~/.wp-cli/packages # composer require runcommand/precache:dev-master
./composer.json has been updated
Running composer update runcommand/precache
Loading composer repositories with package information
Updating dependencies
Lock file operations: 1 install, 0 updates, 0 removals
  - Locking runcommand/precache (dev-master 84093d0)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Installing runcommand/precache (dev-master 84093d0): Extracting archive
Generating autoload files

~/.wp-cli/packages # composer require runcommand/precache:dev-master#009de30
./composer.json has been updated
Running composer update runcommand/precache
Loading composer repositories with package information
Updating dependencies
Lock file operations: 0 installs, 1 update, 0 removals
  - Upgrading runcommand/precache (dev-master 84093d0 => dev-master 009de30)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 0 installs, 1 update, 0 removals
  - Downloading runcommand/precache (dev-master 009de30)
  - Upgrading runcommand/precache (dev-master 84093d0 => dev-master 009de30): Extracting archive
Generating autoload files

Closing this here as I really don’t see what to do about it. If someone can still reproduce this, please reach out to me before changing anything and then maybe I can inspect things on packagist.org.

Ok yeah I have a hard time believing this sorry 😄 I am 100% sure that works for me, already in v1. It might take a minute or two for the metadata update to happen (that is a bit faster for composer 2), but otherwise it should absolutely work.

I’ve bumped into this a couple of times and was scratching my head as to why it worked on some of my repos and not others. I’ve noticed that in the repos where it works “as expected”, I have the following configuration on my composer.json:

"config": {
        "preferred-install": "dist"
},

I suppose when that’s the case the behavior for composer to pull the sources is slightly different (ie: it doesn’t git clone the repo, since it seems to default to source as the preferred-install config).

+1 I think I had issues related to something this feature could fix. During deployment some servers failed to checkout the correct commit object (Git)