-
Notifications
You must be signed in to change notification settings - Fork 11.1k
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
[5.4] [WIP] Fix container #19178
[5.4] [WIP] Fix container #19178
Conversation
Thanks |
@laurencei for this fix, we were just hit with the bug that resolving with parameters did not load the deferred service provider. PS: we verified that this change fixes it for us @taylorotwell any chance cutting a release? 😄 |
Could this somehow be related to the container discarding passed parameters in 5.5? Getting a app(ApiService::class, ['myrandomid']);
class ApiService {
public function __construct(string $key)
{
//
}
} Using the See also #17556 (comment). Was fixed in #18271 (discussion: laravel/ideas#391). |
@sebastiaanluca does the issue occur in the latest version of 5.4? I dont know why it would stop in 5.5 if it was working in 5.4? |
Verified this does not work in a clean 5.4 and 5.5 installation, even without type hints.
Not sure why it stopped working, don't know what exactly changed in the mean time. I drilled down the chain of execution and noticed it never receives any parameters. They don't get explicitly passed (as you've mentioned in your opening post, the I'll create a new issue, but I doubt I'll get an answer anytime soon. Lots of issues and little time unfortunately. |
@sebastiaanluca Does it work if you remove the primitive type-hint? |
No, all passed parameters are discarded. See #21147. |
This is an attempt to fix #19175
The current
getClosure()
does the following call:return $container->$method($concrete, $parameters);
But
$method
can only ever bemake($abstract)
orbuild($concrete)
. Both of these only take a single parameter as of ff993b8 - yet we are trying to pass in 2 parameters.The problem is if you originally called
makeWith()
- and you end up down this path due to an interface being used, you end up with$parameters
dropping off and not being passed along whenmake()
is called here.The limitation we have to work with is there cant be an interface change for 5.4. So we cant change
make()
to accept the second$parameters
(which is probably the best solution here).This PR switches the
getClosure()
to use themakeWith()
, allowing the parameters to happily continue along until they are needed.But - switching to
makeWith()
we create another issue:Application.php
extends themake()
function, to load any deferred providers. We need to also allow that to occur formakeWith()
?I've labelled this WIP - because although all the tests are green - I'm worried about unintended side effects here. Specifically would anyone have a custom implementation of Application that does not extend the Framework version? What would occur to their deferred providers in that instance?
I think we should get some people to test in real applications and see before we commit this.
The alternative is we leave the behavior as is for 5.4, and just fix it in 5.5 with a contract change, which will allow for a better and safer refactor, rather than doing this on a point release?