Closed benr77 closed 3 years ago
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?
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
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.
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
.
@ondrejmirtes in this case phpstan is installed in its own bin namespace and only shares dependencies with its plugins
@jakzal I'm not aware of a plugin that would have symfony/translation
in the require
section.
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.
@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)
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.
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.
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.
@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?
@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.
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.
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.