Config generation on global installation

[umulmrum]

Hi,

I have the following constellation:

• PHPStan is installed globally (composer global require ...)
• My project is of course "local" and I use PHPStan there.

My problem is as follows:

• I run PHPStan after setup, and results are as expected.
• Then I run composer install locally in the project.
• When I run PHPStan again, the scan fails.

This is because the extension installer re-generates the GeneratedConfig on composer install, and because there are no extensions installed locally, the config is now empty. This leads to some code not being correctly interpreted because the extensions are ignored.

Is there anything I need to do, or do you have other advice? Thanks! :-)

[ondrejmirtes]

Hi, I don't understand this problem, can you list the exact steps that lead to this problem? I don't understand why running composer install locally in the project would lead to executing a plugin from the global installation.

Anyway, your best best is to install PHPStan locally in your project, which will remove your headaches like these, and is the recommended option anyway (https://phpstan.org/user-guide/getting-started).

[umulmrum]

@ondrejmirtes Thanks for your reply. These are the steps (I didn't doublecheck, so there might be mistakes in them, but I think the way in general gets clear):

• composer install in the project directory (so all dependencies are available). Do NOT install PHPStan in the project.
• composer global require phpstan/phpstan phpstan/extension-installer phpstan/phpstan-doctrine (I include more extensions, but the Doctrine one should be enough for the example).
• Define a Doctrine entity with a mapped generated ID without write accesses (as Doctrine handles those in the background). See below for an example. Without the extension this would fail with "$id is never written, only read".
• phpstan analyse (on level 9) within the project directory, using the globally installed PHPStan. The check passes because of the extension.
• composer install in the project directory. This overwrites the GeneratedConfig in the global PHPStan installation.
• phpstan analyse again. Now the check fails because the extension is no longer active.

Example entity (reader, but no setter):

class MyEntity
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column(type: 'integer')]
    private int $id;

    public function getId(): int
    {
        return $this->id;
    }
}

I'd like to avoid installing quality tools as project dependencies, to a) have them completely independent and "un-interfering", and b) only need a single installation in a monorepo to simplify maintenance.

[scollovati]

I had the same issue today: https://github.com/TomasVotruba/type-coverage/issues/10#issuecomment-1711791438

By uninstalling the global "auto-installer" everything goes fine. However, having the possibility of using PHPStan with extensions both locally and globally with the auto-installer would be great.

Until this issue is solved, the only possibility is to include manually the config files.

NB: it seems the same issue referenced here https://github.com/phpstan/extension-installer/issues/76#issuecomment-1657099451

[michaellehmkuhl]

I also ran into this issue. Thanks @scollovati for the hint about uninstalling.

After I removed it with composer global uninstall phpstan/extension-installer, my local project composer install correctly populated the GeneratedConfig.php in my project vendor directory.

[umulmrum]

FYI I ended up adding a call to composer global install to the composer script that runs PHPStan, so the issue is automatically handled on each execution.