Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Support for parameterised service class #254

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ondrejmirtes merged 5 commits into phpstan:master from Wirone:class-param-resolution
Feb 25, 2022

Conversation

Copy link
Contributor

@Wirone Wirone commented Feb 9, 2022
edited
Loading

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 🙂

Copy link
Member

/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?

Copy link
Contributor Author

Wirone commented Feb 10, 2022

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.

Copy link
Collaborator

Seems ok to me, go ahead.

Copy link
Contributor Author

Wirone commented Feb 10, 2022
edited
Loading

@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 Wirone force-pushed the class-param-resolution branch from 7a9ecd4 to 368e737 Compare February 10, 2022 23:22
- Explicit requirement for `symfony/dependency-injection`
- Do not use `psr/log` 1.1.2 (see: symfony/symfony#44371 (comment))
@Wirone Wirone force-pushed the class-param-resolution branch from 368e737 to d10d156 Compare February 10, 2022 23:43
Copy link
Contributor Author

Wirone commented Feb 10, 2022

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 🙂

Grzegorz Korba added 2 commits February 11, 2022 17:14
Versions 1.1.0 and 1.1.2 does not work properly with Symfony DI (`Psr\Container\ContainerExceptionInterface` extends `\Throwable` there and it causes errors for DI's exception which also extends it).
@Wirone Wirone force-pushed the class-param-resolution branch from 4425c13 to 46e535d Compare February 14, 2022 08:12
Copy link
Contributor Author

Wirone commented Feb 25, 2022

@ondrejmirtes @lookyman any chance for merging this?

@ondrejmirtes ondrejmirtes merged commit 261955f into phpstan:master Feb 25, 2022
Copy link
Member

Thank you.

@Wirone Wirone deleted the class-param-resolution branch February 25, 2022 13:47
Copy link

Seldaek commented Feb 25, 2022
edited
Loading

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?

Copy link
Member

@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

Copy link

Seldaek commented Feb 25, 2022

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

Copy link
Contributor Author

Wirone commented Feb 25, 2022

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

Copy link

Seldaek commented Feb 25, 2022

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

Wirone reacted with thumbs up emoji

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@ondrejmirtes ondrejmirtes ondrejmirtes left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Services with parameterised class are not resolved

AltStyle によって変換されたページ (->オリジナル) /