I don't get the point of this. Seems like yet another worthless file I'll have to remove from every app I make like the console routes file. And seems directly contrary to th direction Laravel went with 11.x for slimming the skeleton.

If you want it just add it yourself to your app.

Yeah this should be either apart of the framework's existing helpers or added yourself to your own project.

With the new--using flag in the installer you can make your own starter with this

We already have Laravel's default middlewareauth andguest, this is useless.

I usually add ahelpers.php file to my app's./app folder and namespace it onApp, something like this:

<?phpnamespaceApp;functionfoo() {}

It is still short enough to use in views ({{ \App\foo() }}), and in regular code I can import it. And has the benefit of not polluting the global namespace.

I would vote to have the helpers file under./app, as it is application's code.

I can see the benefit of having this file included on the likes to show users how easy, and useful, it is to have a helpers file.

Much like what we have in./route/console.php, which ships with theinspiring command, and anyone who doesn't want that command can easily remove it on their app.

It also has the additional benefit of an added helper file that will come with the project, most of the devs had to add that file to their project manually. Maybebootstrap/ is not the right place, but the idea in itself is not bad.

In my opinion, it's not a necessary functionality. Even if it was, it does not consider all possible situations. For example, what if someone (like me) uses a custom-curated class for the user entity that does not extend the App\Models\User?

I think this is an issue for the vscode extension honestly. There has got to be a good way somehow to configure static analysis to bind preferred, current or default implementations for contracts in general.

I honestly feel the OP's pain. I do, but this is part of a larger problem.Authenticatable is one of many cross cutting, integral contracts provided and fulfilled by the framework. If only we could globally configure the ones we're most concerned with somehow using some kind of config map? Preferably not in yaml. 😅

Agree that this is necessary. Also agree that improving the IDE extension is the way to go. Laravel needs a best-in-class IDE that works out of the box without having to install a bunch of things to get it to work.

Now that Laravel Cloud exists, the IDE is the last painful point that sucks for literally every developer. PHPStorm wont do anything and defers everything to the IDEHelper (BLESS BARRYV) but it adds a ton of bloat.

VSCode is the obvious choice and the official extension is really the future. We shouldn't be making framework choices based on IDEs being bad at what they do. Instead we should be improving the IDE extension.

PHPStorm wont do anything and defers everything to the IDEHelper (BLESS BARRYV) but it adds a ton of bloat.

The Laravel IDEA plugin is worth every cent, and works incredible well with (most) type analysis needed on a Laravel project.

PHP Storm offers the Laravel IDEA plugin at a discounted rate when licensing both the IDE and the plugin together.

I am not affiliated to PHP Storm nor to the Laravel IDEA plugin, just a satisfied client of both tools

PHPStorm wont do anything and defers everything to the IDEHelper (BLESS BARRYV) but it adds a ton of bloat.

The Laravel IDEA plugin is worth every cent, and works incredible well with (most) type analysis needed on a Laravel project.

PHP Storm offers the Laravel IDEA plugin at a discounted rate when licensing both the IDE and the plugin together.

I am not affiliated to PHP Storm nor to the Laravel IDEA plugin, just a satisfied client of both tools

I've paid for both and went to vscode anyway. Caleb's make vscode awesome already puts it ahead of phpstorm, and with intelephense (the paid version) and the Laravel vscode extension, it's miles ahead. If we can invest more in a 1st party extension, it solves all of these issues. Case in point, we have talented developers sending pull requests for functions that have been around from day 1 because IDEs are still painful even for veterans.

I always create a method calledUser::auth() on my user to get proper hints.

class User {publicstaticfunctionauth():self {$user =auth()->user();throw_if(!$user, Exception::class,"Called from invalid auth context!");return$user;    }}

I always create a method calledUser::auth() on my user to get proper hints.

This might be interesting to add to\Illuminate\Auth\Authenticatable, however, that won't solve@imliam's original problem 🤔

Ignoring other issues, this will need manual tweaking as soon as someone uses another Authenticatable class.
What I do is add something like this in a.ide.php file

namespaceIlluminate\Contracts\Auth {interface Guard    {publicfunctionuser():\App\Models\User;    }}

I don't usually reach forbarryvdh/laravel-ide-helper in simple cases like this.

I think your idea is excellent, but the way it’s been implemented doesn’t align with the framework’s current structure. Depending on the project, we might have multiple authentication models or models organized into separate folders in modular architectures. The helper should be flexible enough to handle these cases. If you can refine your approach, it would make a wonderful contribution ❤️🚀