In my CI pipelines I just run php bin/console --env=dev > /dev/null before phpstan analyse with whatever --env I need. Works like a charm.

I have tentative plans to implement "smart" automatic container detection (with features like choosing the test one when analysing tests). But I can't promise anything at the moment.

In my CI pipelines I just run php bin/console --env=dev > /dev/null before phpstan analyse with whatever --env I need. Works like a charm.

Current PHPStan's configuration leaves you with the requirement of making hacks on CI or locally. If you leave the dev env in phpstan.neon.dist then you need to make hacks on CI (to run it in test env). If you put the test env in phpstan.neon.dist then you need to make hacks to run it locally (to run it in dev env). The easiest way is creating a phpstan.neon file with the config that works, but the fun comes when you use a multi-environment setup - not only the standard dev and test, but for example qa because you have a local copy of your QA's database because he asked you to debug something. Then PHPStan is crying about the missing container if you forget to switch it back to the original env and you removed all cached ones. With this fix our devs wouldn't have to configure anything and the ones that have multi-env setup could define their possible locations for containers.

I have tentative plans to implement "smart" automatic container detection (with features like choosing the test one when analysing tests). But I can't promise anything at the moment.

I know this isn't ideal, but this solution is just a workaround to the problem that I've managed to do in a short amount of time.

Hi, I don't think this complexity is needed, I think phpstan-symfony as it is works for all Symfony apps, albeit you need to dump the right container before running PHPStan. It's totally fine. Thanks for understanding.