PHPStan & Symfony version issue???

[benr77]

Using toolbox 1.39.0 and phpqa 1.49.0 on my Symfony 4.4.19 project.

At the end of every PHPStan analysis I get several errors like this.

Child process error (exit code 255): Warning: Declaration of                                                     
Symfony\Component\Translation\DependencyInjection\TranslatorPathsPass::processValue($value, bool $isRoot =       
false) should be compatible with                                                                                 
Symfony\Component\DependencyInjection\Compiler\AbstractRecursivePass::processValue($value, $isRoot = false) in   
/tools/.composer/vendor-bin/phpstan/vendor/symfony/translation/DependencyInjection/TranslatorPathsPass.php on    
line 82                                                                                                          
Fatal error: Declaration of Symfony\Bridge\Monolog\Processor\DebugProcessor::getLogs() must be compatible with   
Symfony\Component\HttpKernel\Log\DebugLoggerInterface::getLogs(?Symfony\Component\HttpFoundation\Request         
$request = NULL) in /project/vendor/symfony/monolog-bridge/Processor/DebugProcessor.php on line 64 

It is complaining about a method signature mismatch between (I think!) my Symfony installation which is being analysed, and /tools/.composer/vendor-bin/phpstan/vendor/symfony/translation/DependencyInjection/TranslatorPathsPass.php which appears to be a Symfony component as part of the PHPStan installation.

I can't find any existing issues here, on phpqa or phpstan repos. Can you shed any light on this?

If it's a PHPStan issue just let me know and I'll submit an issue over there. PHPStan has switched to a PHAR format and I think this means that in its standalone form this kind of issue shouldn't happen - hence me posting here first.

Thanks for any help.

[jakzal]

PHPStan is installed as a phar. I assume they prefixed the phar so it shouldn't conflict with your project. Perhaps extensions are the problem?

@dkarlovi what do you think?

[benr77]

Ah I should have checked the PHPStan extensions - I'm using a few.

On one project it seems I can get rid of the errors not by disabling the Symfony extension itself, but by removing the console_application_loader config option.

However, on a different project, I'm removing ALL extensions and still getting the following error:

Child process error (exit code 255): Fatal error: Declaration of                                                         
Symfony\Bridge\Doctrine\DataCollector\DoctrineDataCollector::collect(Symfony\Component\HttpFoundation\Request $request,  
Symfony\Component\HttpFoundation\Response $response) must be compatible with                                             
Symfony\Component\HttpKernel\DataCollector\DataCollectorInterface::collect(Symfony\Component\HttpFoundation\Request      
$request, Symfony\Component\HttpFoundation\Response $response, ?Throwable $exception = NULL) in                          
/project/vendor/symfony/doctrine-bridge/DataCollector/DoctrineDataCollector.php on line 62

Any thoughts?
Thanks

[dkarlovi]

There's an issue with PHPStan needing to be installed directly into the project when using extensions. Sadly, currently there doesn't seem to be a way to both use extensions and use PHPStan from a Phar.

Maybe @ondrejmirtes wont mind me spamming too much and just confirm / deny this.

[ondrejmirtes]

I recommend not using vendor-bin for PHPStan at all, it's problematic. PHPStan is designed from the ground up to be installed as require-dev dependency in your project without any downsides.

What's going on - you have multiple things installed in vendor-bin, and they share some dependencies. PHPStan sees those dependencies first before the dependencies of the analysed project. And they're not compatible.

Path /tools/.composer/vendor-bin/phpstan/vendor/symfony/translation/DependencyInjection/TranslatorPathsPass.php IS NOT part of PHPStan installation, but of something else you have installed in vendor-bin.

[jakzal]

@ondrejmirtes in this case phpstan is installed in its own bin namespace and only shares dependencies with its plugins

[ondrejmirtes]

@jakzal I'm not aware of a plugin that would have symfony/translation in the require section.

[benr77]

I have a few more of these error messages that I can paste in if that would be helpful?

EDIT: Although as I mentioned above, I still get one of the errors without any extensions configured at all, although they are of course still existing as part of the phpqa package which is where the PHPStan installation is being used from.

[jakzal]

@ondrejmirtes it's the larastan plugin:

/tools/.composer # composer bin phpstan depends symfony/translation
nesbot/carbon  2.43.0  requires  symfony/translation (^3.4 || ^4.0 || ^5.0)
/tools/.composer # composer bin phpstan depends nesbot/carbon
illuminate/support  v8.20.1  requires  nesbot/carbon (^2.31)
/tools/.composer # composer bin phpstan depends illuminate/support
illuminate/console     v8.20.1  requires  illuminate/support (^8.0)
illuminate/database    v8.20.1  requires  illuminate/support (^8.0)
illuminate/filesystem  v8.20.1  requires  illuminate/support (^8.0)
illuminate/http        v8.20.1  requires  illuminate/support (^8.0)
illuminate/pipeline    v8.20.1  requires  illuminate/support (^8.0)
illuminate/session     v8.20.1  requires  illuminate/support (^8.0)
nunomaduro/larastan    v0.6.11  requires  illuminate/support (^6.0 || ^7.0 || ^8.0)

[ondrejmirtes]

I went through this list: https://github.com/jakzal/toolbox/blob/master/resources/phpstan.json

So the cause is probably Larastan which has a huge require section: https://github.com/nunomaduro/larastan/blob/master/composer.json

@benr77 I recommend you installing phpstan/phpstan directly in your composer.json, you will get rid of problems like these.

[benr77]

Ok, so at least the root cause is now discovered. Thank you both for that.

I've been trying to remove all my coding standards packages from my projects and rely solely on phpqa as it's much easier to deal with that one install.

[ondrejmirtes]

I don't think there's any overhead with dealing with phpstan/phpstan separately on its own. You still need to have project-specific phpstan.neon anyway, so treating the tool as a first class citizen when it comes to managing upgrades isn't much of a hassle.

[benr77]

@jakzal Is it possible for me to build a customised phpqa which does not have the larastan extension? I see the instructions on how to make a custom docker build but I guess in this case I need to modify what's coming from the toolbox repo? Or would it just be a case of using the composer-bin-plugin to remove the larastan extension?

[jakzal]

@benr77 can you create a new issue for this use case and we'll discuss it there please? toolbox has options to support it, but I'm not sure if the docker image makes it easy 🤔

For now removing the larastan extension might be the quickest workaround.