Plugin commands are hidden in Composer available commands

[edersoares]

In version 2.1.6 after 9727adf custom commands added by plugins are not listed in "Available commands" like version 2.1.5 and older.

It's not a big problem because if you know the name of the command and run it, it's still working, but is not a good user experience.

My composer.json:

{
    "name": "my/project",
    "autoload": {
        "psr-4": {
            "My\\Project\\": "src/"
        }
    },
    "require": {
        "my/plugin-package": "*"
    },
    "repositories": [
        {
            "type": "path",
            "url": "./plugin"
        }
    ],
    "minimum-stability": "dev"
}

My plugin package following https://getcomposer.org/doc/articles/plugins.md#creating-a-plugin doc (simplified and living in ./plugin folder):

{
    "name": "my/plugin-package",
    "type": "composer-plugin",
    "autoload": {
        "psr-4": {
            "My\\": "./"
        }
    },
    "require": {
        "composer-plugin-api": "^2.0"
    },
    "require-dev": {
        "composer/composer": "^2.0"
    },
    "extra": {
        "class": "My\\Plugin"
    }
}

# Plugin and Command Provider

namespace My;

use Composer\Composer;
use Composer\IO\IOInterface;
use Composer\Plugin\Capability\CommandProvider;
use Composer\Plugin\PluginInterface;
use Composer\Plugin\Capable;

class Plugin implements PluginInterface, Capable, CommandProvider
{
    public function getCapabilities()
    {
        return array(
            CommandProvider::class => static::class,
        );
    }

    public function getCommands()
    {
        return [
            new Command(),
        ];
    }

    public function activate(Composer $composer, IOInterface $io)
    {
    }

    public function deactivate(Composer $composer, IOInterface $io)
    {
    }

    public function uninstall(Composer $composer, IOInterface $io)
    {
    }
}

# Command

namespace My;

use Composer\Command\BaseCommand;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;

class Command extends BaseCommand
{
    protected function configure()
    {
        $this->setName('command');
    }

    protected function execute(InputInterface $input, OutputInterface $output)
    {
        $output->writeln('Executing command');
    }
}

Output of composer diagnose:

Checking composer.json: WARNING
No license specified, it is recommended to do so. For closed-source software you may use "proprietary" as license.
require.my/plugin-package : unbound version constraints (*) should be avoided
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com oauth access: 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.1.6
PHP version: 8.0.7
PHP binary path: /usr/local/Cellar/php/8.0.7/bin/php
OpenSSL version: OpenSSL 1.1.1k  25 Mar 2021
cURL version: 7.77.0 libz 1.2.11 ssl (SecureTransport) OpenSSL/1.1.1k
zip: extension present, unzip present, 7-Zip not available

When I run this command:

composer
composer list

I get the following output: only default Composer commands, without custom commands added by plugin.

[stof]

The list command should probably be made special in this optimization logic.

[mvorisek]

The problematic change was introduced in 9727adf and described in #10064 as multiple git commands were executed but not needed. My question is, shouldn't we prevent to execute the slow commands in the first place/instead?

[Seldaek]

@mvorisek These aren't very slow in most cases, but depending on the state of your git repo it may become a little slow. For example I get init times around 100-200ms depending on the branch I'm on here which is IMO acceptable. This is also not really something we can easily skip as it means we do not know the version of the root package, which can lead to issues in some cases down the line.

[Jduret]

Does the fix is just about adding "help" to the list ?

|| in_array($commandName, array('', 'list'), true)

|| in_array($commandName, array('', 'list', 'help'), true)

If yes, I've requested the change in this PR