-
Notifications
You must be signed in to change notification settings - Fork 11k
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
[6.x] Remove Container dependency on Illuminate\Support #30518
[6.x] Remove Container dependency on Illuminate\Support #30518
Conversation
For standalone projects, pulling in all of Illuminate\Support is a bit overkill, given that we're using only a couple of functions from the package. This commit opts to duplicate the two helper functions inside the container namespace (so they'll be picked up by a subtree split), which also removes reliance on any custom global functions. This goes beyond effectively reverting #29959, as the container used Arr::wrap() before adding in the value() helper.
Maybe it's worth Laravel making a lighter support component, with fewer dependencies, and then have the main support component depend on that? It seems odd for the framework code to copy bits of itself into components, instead of using dependencies properly? |
My solution is definitely a half measure, but I wasn't about to propose a significant architectural change to how illuminate/support is built, as it isn't really my place. Seems like the half measure would be reasonable for now, and when e.g. arrays and the value() helper (which should be namespaced) get split out those support components could be pulled in at that point in lieu of the custom methods. |
I agree with @GrahamCampbell. It seems to be reasonable to have smaller components and not to pull in all utilities as single batch. Architectural changes could be addressed to |
I favour the change but IMHO this shouldn't go into 6.x Btw, I really like the name |
@mfn Why not in 6.x? This isn't a BC break; if you're relying on illuminate/support in a standalone app that uses the container, you should be requiring the package directly. |
Thanks for the merge, @taylorotwell! |
Tbh, I wouldn't make the support component any lighter. I don't see the benefit in having more components which would be support-for-x, support-for-y (just for example). I think things are fine as they are. @iansltx good pr 👍 |
public function testUnwrapIfClosure() | ||
{ | ||
$this->assertSame('foo', Util::unwrapIfClosure('foo')); | ||
$this->assertSame('foo', UtiL::unwrapIfClosure(function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@iansltx I noticed a capital L
on this line.
Actual: UtiL::unwrapIfClosure
Expected: Util::unwrapIfClosure
// @driesvints
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoops.
Mind PR'ing a typo fix here, as this has already been merged?
For standalone projects, pulling in all of Illuminate\Support is a bit overkill, given that we're using only a couple of functions from the package. This chage opts to duplicate the two helper functions inside the container namespace (so they'll be picked up by a subtree split), which also removes reliance on any custom global functions.
This goes beyond effectively reverting #29959, as the container used Arr::wrap() before adding in the value() helper.
Tests are carbon copies of the equivalent Illuminate\Support tests.