search

drupal-code-builder / drupal-code-builder-drush

Drush commands for Drupal Code Builder. Use the branch that matches the Drush version.
13 stars 3 forks source link

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

Open jurgenhaas opened 8 months ago

jurgenhaas commented 8 months ago

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

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:

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

Not sure what else I could test.

joachim-n commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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!