When I click it, I will navigate to Illuminate/Facade/ whatever, but the real class that will be injected with autoload lives in /swiftmailer/Swift/. Autoloader will overload the classes and fix this. The latter case is probably the same reason. So do I get it right that the first issue is due to the autoloader that injects everything? I experience the same issues with other classes and it's crazy and annoying when trying to understand Laravel and following the classes. There's a few other issues tracking similar problems so I'll close this one as a solution has been provided for the global facade aliases. PHP has no inline casting like other languages which would help solve this eg (auth())->someUserMethod() so that is tricky to solve. However, other issues exist too in various places because interfaces are returned from functions/methods which don't declare all the methods that users expect from their configured concrete types. I'm looking at relaxing this minimal type reduction which may help here. StatefulGuard is a subtype of Guard so this return type gets reduced to a minimal type SuperType|SubType => SuperType. The issue with attempt is because user() is annotated to return \Illuminate\Contracts\Auth\Guard|\Illuminate\Contracts\Auth\StatefulGuard. If you don't want to use ide helper you can also use the FQN as suggested above and avoid the global aliases, or even turn off. Intelephense doesn't pick them up because there are no declarations eg class Auth, laravel creates them at runtime. To provide Auth and other global facade aliases you can use. Maybe there is something like an alternative extension that will fix those problems for me? I just don't want to end up editing hundreds of files for each Laravel project that ends up on my table for further work. I would really welcome if this could be addressed. PHPStorm manages to deal with this, properly, I have hard times to understand why this extension cannot. It's a serious time waster to refactor everything so it complies with PHP Intelephense over and over again, but on the other hand it's irritating, because I never know if the error I see is serious or not. You see, I'm glad for your advice, but I'm dealing with a lot of projects (including Laravel projects) that I have to modify, enhance and ship, regularly. I don't want to appear unthankful, I'm not, I'm glad this extension exists so I don't have to use PHPStorm, but for my case it's still hard to use. This is probably another edge case, but the point of this GitHub issue is not to convert each and every case (refactoring), instead the extension should not mark those cases as errors when they are work as intended, because this is valid working Laravel PHP code. It also seems to fail with methods that come from the AuthFactory and the lists goes on: In this particular case your solution works, but it's not a solution that I can go with, because I'm dealing with a working Laravel project that is full of those cases.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |