composer / installers

A Multi-Framework Composer Library Installer

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

"Could not scan for classes" warnings when used with other Composer plugins

danepowell opened this issue · comments

Something about the way that Composer Installers implements its Composer plugin is throwing warnings and errors when included in downstream projects alongside other Composer plugins. Both BLT and composer-merge-plugin have seen this, among others:

I've created a minimum failing example to demonstrate the issue: https://github.com/acquia/blt/tree/issue-3148-demo

Reproducing this is very easy. Simply create the following composer.json in a test directory, which just requires the above branch:

{
    "name": "example/demo",
    "description": "Composer installers error demo",
    "type": "project",
    "minimum-stability": "dev",
    "prefer-stable": true,
    "license": "GPL-2.0-only",
    "require": {
        "acquia/blt": "dev-issue-3148-demo",
        "composer/installers": "^1.2.0"
    }
}

Then run composer install && composer --version in the test directory. You'll see a cascade of warnings like this:

Could not scan for classes inside "vendor/drupal/core/lib/Drupal.php" which does not appear to be a file nor a folder

You can see that that demo branch essentially just contains an empty plugin and a requirement on Drupal core and Composer installers, which is what leads me to believe that Composer installers is part of the root cause somehow.

Interestingly, if you install BLT locally and rename it to zacquia/blt the error goes away, indicating that this is a race condition.

I'm actually not sure that Composer Installers is doing anything wrong here, or will be able to solve this on its own. I think it's at least partly a problem with how Composer loads plugins: composer/composer#8065

However additional action may be required of Installers depending on the resolution of that issue.

Thanks so much for taking on this issue @danepowell :) Hopefully we can get someone to approve and merge composer/composer#8085 ASAP

Is this still actual? I guess it's been resolved composer side?

I think it was resolved in one of the Composer PRs that made package sorting deterministic. I can't verify because we deleted the BLT testing branch used in the steps to reproduce.

If I see it again I'll open a new issue.