Legacy package index prevents installation of current release of a package about package-command

[aaemnnosttv]

@selul I've been looking into this too and it looks like using canonical: false should fix the problem, but it doesn't.

After editing ~/.wp-cli/packages/composer.json to mark the wp-cli composer repository as canonical: false, if I run wp package list, the resulting output correctly reports that an update is now available where it wasn't before.

However, running wp package update still results in no change to the installed packages, and there does not seem to be a way to force this. Even removing the package and reinstalling it still installs the stale version of the package, even using Composer directly.

I found that adding packagist to the list of repositories before wp-cli fixed the problem for me (as my packages are all listed on Packagist (as is pressbooks/pb-cli).

 {
     "name": "wp-cli/wp-cli",
     "description": "Installed community packages used by WP-CLI",
     "version": "2.5.0",
     "authors": [
         {
             "name": "WP-CLI",
             "email": "[email protected]"
         }
     ],
     "homepage": "https://wp-cli.org/package-index/",
     "require": {
         "aaemnnosttv/wp-cli-dotenv-command": "dev-master"
     },
     "require-dev": {},
     "minimum-stability": "dev",
     "prefer-stable": true,
     "license": "MIT",
     "repositories": {
+        "packagist": {
+            "type": "composer",
+            "url": "https://repo.packagist.org/"
+        },
         "wp-cli": {
             "type": "composer",
             "url": "https://wp-cli.org/package-index/"
         }
     },
     "config": {
         "secure-http": true
     }
 }

If we had wp-cli as a non-canonical Composer repository, I would expect this to have the same behavior (a newer version of the package existing in another repository), but it seems that this specifically may be an upstream bug.

It's probably a good idea to update the definition of the wp-cli repository to use canonical: false anyways since it's almost guaranteed to be out-of-date, so this would be the more accurate definition of the repository IMO. Assuming there is an upstream bug, the above packagist repo order workaround should no longer be necessary.

[selul]

Might be solved if we set the WP-CLI Package Index as non-canonical, i.e canonical: false, more details about this here

I can help to send a PR if this is a good idea.