You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
NarrowObjectReturnTypeRector replaces interface with implementing concrete class #9525
No changes in the return type of Vhost\Healthz::handle. My expectation here was that Rector would respect the return type and anyone call that method should care about how I get to my return value, only that it implements that interface.
I agree with @WyriHaximus . I think we'll have to skip such cases, as it's not first time this was reported.
It makes sense for implemented method, where it narrows the type. Here it would only override existing declared type.
@TomasVotruba how about make it configurable? eg: allow_interface_to_exact_type, default to true?
I'd prefer to exclude the case above, as its out of scope of this rule. There must be some parent method (interface or class) we override, so the narrow type in the rule name happens.
I check the fixtures and the origin PR about this, there are valid arguments which interface/abstract should be allowed, I think configurable should be the way, it can be true or false, but make it configurable is better imo.
I will create a PR for it so it can be usefull, while allow user to configure it.
I created PR to make it configurable, imo, based on the long discussion we had in the original PR, this still valid, but make it configurable so user can choose the design they want:
Activity
samsonasik commentedon Dec 1, 2025
This is expected, the purpose is clear to get exact type when possible. You can skip the rule if needed
https://getrector.com/documentation/ignoring-rules-or-paths
WyriHaximus commentedon Dec 1, 2025
This honestly wasn't expected, for the example on https://getrector.com/rule-detail/narrow-object-return-type-rector I get it, but a class implementing the interface you have as return type, no.
Yeah I'm aware of that and will do that assuming this behavior won't be fixed, would have been nice if that could be done like PHPStan does with:
/** @rectorphp-ignore NarrowObjectReturnTypeRector */TomasVotruba commentedon Dec 1, 2025
I agree with @WyriHaximus . I think we'll have to skip such cases, as it's not first time this was reported.
It makes sense for implemented method, where it narrows the type. Here it would only override existing declared type.
samsonasik commentedon Dec 1, 2025
@TomasVotruba how about make it configurable? eg: allow_interface_to_exact_type, default to true?
WyriHaximus commentedon Dec 1, 2025
@samsonasik Or make it a list of configurable interfaces?
samsonasik commentedon Dec 1, 2025
That also can be an option 👍
TomasVotruba commentedon Dec 1, 2025
I'd prefer to exclude the case above, as its out of scope of this rule. There must be some parent method (interface or class) we override, so the narrow type in the rule name happens.
samsonasik commentedon Dec 1, 2025
I think interface with
Psr\\prefix can be skipped thenTomasVotruba commentedon Dec 1, 2025
@samsonasik No parent class/interface → skip 👍
samsonasik commentedon Dec 1, 2025
no parent class can be
JsonResponse->Response->ResponseInterface, while user may return:which
Responsecan beJsonResponseinstead, that bothResponseandJsonResponseare instantiable.samsonasik commentedon Dec 1, 2025
I check the fixtures and the origin PR about this, there are valid arguments which interface/abstract should be allowed, I think configurable should be the way, it can be true or false, but make it configurable is better imo.
I will create a PR for it so it can be usefull, while allow user to configure it.
samsonasik commentedon Dec 1, 2025
I created PR to make it configurable, imo, based on the long discussion we had in the original PR, this still valid, but make it configurable so user can choose the design they want:
TomasVotruba commentedon Dec 2, 2025
Fixed in released in https://github.com/rectorphp/rector/releases/tag/2.2.11
WyriHaximus commentedon Dec 2, 2025
Not that I was doubting, but can confirm this resolves the issue for me <3! Thank you all
TomasVotruba commentedon Dec 2, 2025
Thank you @WyriHaximus 👍
github-actions commentedon May 3, 2026
This issue has been automatically locked because it has been closed for 150 days. Please open a new issue if you have a similar problem.