Class "Drush\Commands\drupal_code_builder_drush\Drush\Commands\CodeBuilderDevDrushCommands" does not exist

[jurgenhaas]

This is a follow-up issue to #12 with version 10.0.0 and I'm using the following components:

• Composer 2.7.0
• PHP 8.2.13
• Drush 12.4.3.0

When I run Drush, I only get the following output, no further stacktrace:

$> vendor/bin/drush --debug

 [preflight] Config paths: /drupal/vendor/drush/drush/drush.yml,/drupal/drush/drush.yml
 [preflight] Alias paths: /drupal/web/drush/sites,/drupal/drush/sites
 [preflight] Commandfile search paths: /drupal/vendor/drush/drush/src,/drupal/drush
 [preflight] Class "Drush\Commands\drupal_code_builder_drush\Drush\Commands\CodeBuilderDevDrushCommands" does not exist
 [warning] Drush command terminated abnormally. [0.7 sec, 9.69 MB]

In vendor/composer/autoload_psr4.php there is this line:

    'DrupalCodeBuilder\\' => array($vendorDir . '/drupal-code-builder/drupal-code-builder'),
    'DrupalCodeBuilderDrush\\' => array($baseDir . '/drush/Commands/drupal-code-builder-drush'),

And the file drush/Commands/drupal-code-builder-drush/Drush/Commands/CodeBuilderDevDrushCommands.php does exist.

When I remove that file, the error message is the same, but for the CodeBuilderDrushCommands class.

What's strange, the namespace in the file is declared different from what Drush seems to be looking for:

• DrupalCodeBuilderDrush\Drush\Commands = namespace in file
• Drush\Commands\drupal_code_builder_drush\Drush\Commands = namespace that Drush wants to load

So, instead of DrupalCodeBuilderDrush, the prefix is more like Drush\Commands\drupal_code_builder_drush.

Not sure what else I could test.

[joachim-n]

Since your comment on the other issue, I've tried installing this package on a (relatively) simply project, and I can't reproduce this.

My vendor/composer/autoload_psr4.php has:

    'DrupalCodeBuilder\\' => array($vendorDir . '/drupal-code-builder/drupal-code-builder'),
    'DrupalCodeBuilderDrush\\' => array($baseDir . '/drush/Commands/contrib/drupal-code-builder-drush'),

DrupalCodeBuilder is the namespace for drupal-code-builder/drupal-code-builder -- the drupal-code-builder/drupal-code-builder-drush package has a different namespace, DrupalCodeBuilderDrush.

Where has Composer installed drupal-code-builder/drupal-code-builder-drush in your project? I wonder whether this is an installer problem.

[jurgenhaas]

Sorry, my input for the content of vendor/composer/autoload_psr4.php was incomplete, I've just updated it. It's almost the same as yours, except that I don't have the contrib sub-directory. That because the installer paths in my root composer.json are:

      "drush/Commands/{$name}": [
        "type:drupal-drush"
      ]

Everything else seems to be the same as yours.

[jurgenhaas]

I'll test in a fresh Drupal project tomorrow to see if this is somehow related to that one project that I've tested this with so far.

[jurgenhaas]

Unfortunately, we do have this issue on all our customer sites now. They wanted to update last night (we have an auto-update mechanism) and all of them broke in the pipeline, so the updates were skipped and nothing major happened to any of the sites, which is good. There are many different sites structures, and all of them show this issue.

It looks to me that the Drush class loader is somehow getting confused, as it is obviously trying to load that command class from the wrong namespace. Maybe the Drush maintainers have an idea how that could happen by looking at the structure of this package?

[joachim-n]

The location for Drush commands should be:

            "drush/Commands/contrib/{$name}": [
                "type:drupal-drush"
            ],

Try changing it to that and removing then reinstalling this package.

I'm fairly sure that's the problem. If that doesn't work, I've put a __construct() method with a breakpoint in CodeBuilderDevDrushCommands.

The code that tries to instantiate it is Drush\Runtime\ServiceManager::instantiateServices(), so the next thing to try would be debugging in there.

[jurgenhaas]

Confirmed, when the Drush commands get installed in drush/Commands/contrib instead of drush/Commands, then the error disappears. However, that's a bug in my view, since that destination is configurable, why should the location be hardcoded to a specific location only?

[joachim-n]

Looks like I need to update the namespaces and file locations for version 12 of Drush -- https://www.drush.org/12.x/commands/

However, I've had a go at making them follow the spec, and now on my system the command isn't picked up!