Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork1.7k
Remove unusedmount()
arguments from Livewire directive#9194
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
This is for backwards compatibility I believe! |
In that case can we instead add the 2 unused arguments to the mount method? |
@calebporzio since you are the author of3d47803 could you look at this? |
mount()
arguments from Livewire directive0dc0d22
intolivewire:mainUh oh!
There was an error while loading.Please reload this page.
Thanks! |
Uh oh!
There was an error while loading.Please reload this page.
The problem
The
mount()
method inLivewireManager
is defined with 3 parameters:livewire/src/LivewireManager.php
Line 71 in509f225
However, the generated code calls this method with
5 arguments
, which causes PHPStan to report a mismatch. Since the method signature doesn't account for the extra arguments, static analysis sees it as an incorrect method call—even though those extra arguments are unused.This shows up when analyzing Blade templates and can be confusing or noisy for users relying on stricter static analysis levels.
The solution
This PR removes the extra, unused arguments passed to
mount()
, aligning the call with the method’s actual signature. This eliminates unnecessary static analysis warnings without changing any runtime behavior.The conversation
If the extra arguments are included intentionally—for example, to support future use cases or give extended components access to more context—an alternative would be to add the extra parameters to the
mount()
method signature instead. That would preserve compatibility and still satisfy static analysis tools.I'm open to whichever approach makes the most sense long-term!