Support for parameterised service class

[Wirone]

Fixes #226

It's simplest and optimistic implementation which does not support:

• %env()% syntax
• %app.class%_decorator mixed interpolation

Let me know if we can start with this or should we work on most advanced scenarios 🙂

[ondrejmirtes]

/cc @lookyman needs to say if it's okay :)

This is how the % expanding logic looks like in nette/di: https://github.com/nette/di/blob/5ef440ce8c603bb80a4a6459e0842528c5bf64ea/src/DI/Helpers.php#L26-L108

Can't we just call something in Symfony to achieve the same?

[Wirone]

Yeah, it would be great to use some kind of resolver and I'll look at it if needed, I just wanted to know if I hooked into right place with parameter expanding 🙂 So let me know @lookyman if that's correct, so I can work on ServiceDynamicReturnTypeExtension::determineServiceClass() then.

[lookyman]

Seems ok to me, go ahead.

[Wirone]

@lookyman Symfony resolves placeholders in Symfony\Component\DependencyInjection\Compiler\ResolveParameterPlaceHoldersPass when DI container is compiled. Since this extension does not compile container but uses only simple maps (separate for services and parameters) I decided to use ParameterBag which has method for resolving values. So if service's definition uses placeholders, these will be resolved into actual values using parameter bag.

I did not want to create another ParameterMap implementation, but if you don't like current implementation just let me know how would you want it to be.

PS. make locally passes, so Github actions' fail for CS is not related to changes. PHPUnit on highest dependencies fails because of ParameterBag which imports Symfony DI exceptions and the ExceptionInterface is somehow broken... 🙄

[Wirone]

Sorry for the noise, but it took me while to understand why it fails on PHP 7.1. Personally I think it's wrong that packages used in actual code are added as dev dependencies, but now I know that adding them to require causes trouble 😉 These packages now are soft dependencies but probably you assume that they're required by project that uses PHPStan with this extension and will be installed anyway, so analysis will work. Anyway, checks are green, parameter resolving works as expected - my job is done here 🙂

[Wirone]

@ondrejmirtes @lookyman any chance for merging this?

[ondrejmirtes]

Thank you.

[Seldaek]

This created a regression if you're not using a full symfony framework. I use this project in Composer for example and I don't have the DI component installed as I only need the symfony/console type inferrence.

See https://github.com/composer/composer/runs/5334439438?check_suite_focus=true#step:9:10

So I guess it would be good to detect if the class is present before running ServiceDynamicReturnTypeExtension?

[ondrejmirtes]

@Seldaek Sorry for the bug, here's a fix: 8ef80f5

Please test phpstan-symfony 1.1.7 with it, thank you. https://github.com/phpstan/phpstan-symfony/releases/tag/1.1.7

[Seldaek]

It builds again, thanks for the super quick fix! https://github.com/composer/composer/actions/runs/1900486331

[Wirone]

Sorry @Seldaek for causing problems 😳 And thanks @ondrejmirtes for the fix 🍻

[Seldaek]

No worries, it's easy to forget these components are used without the full framework sometimes :)