feat: User defined Class aliases in `.phpantom.toml` (Like 'Illuminate\Contracts\Auth\Authenticatable' = 'App\Models\User')

[AbyssWaIker]

Love the project and all of the good work you are doing

TODO for Laravel mentions "Application provider scanning", "Auth model from config", "Contract → concrete resolution", and "Manager → driver resolution" being all out of scope.

So I had an idea to let users specify this inside of a config (so it get's scanned once on a start up into a hashmap and once key for the hashmap is encountered it can be treated as a value)

This may help both Laravel devs like me and other devs who have different specialized use-cases.

Though recently you have removed "better auth() helper type" from "won't fix", so you may already have an idea how to do it, I'm publishing the issue in case this solution may be more re-usable and may cause less head-aches with people creating their own custom User model with a different path/name and specifying them in config/auth.php

init-ing default toml file with something like:

(update: fixed an obvious oversight of me copying a wrong class)

[aliases]
'Illuminate\Contracts\Auth\Factory' = 'Illuminate\Auth\AuthManager'
'Illuminate\Contracts\Auth\Authenticatable' = 'App\Models\User'

may both solve auth()->user() type error in a re-usable way and inform users of the way this feature works.

I hope even if this won't fit into the project it can give you some ideas for sprints 5-7

[AJenbo]

That's not an entirely bad idea.

Specifically for auth()->user() my recommendation is to make a helper that can be statically analyzed:

use Illuminate\Support\Facades\Auth;

function authUser(): ?User
{
	$user = Auth::user();
	if (!$user instanceof User) {
		return null;
	}

	return $user;
}

Your example also has a mistake, the correct mapping would be:

'Illuminate\Contracts\Auth\Factory' = 'Illuminate\Auth\AuthManager'
'Illuminate\Contracts\Auth\Authenticatable' = 'App\Models\User'

The reason I deem these out of scope is that they are inherently deficiencies in the API contract provided by Laravel and as such it should be fixed in Laravel and not just paved over with hacks in various tools.

Your solution is ok to me since it doesn't try to run the application, and the user is taking responsibility for the lies they are feeding into the system (AuthManager is the default AuthFactory, but it's possible to configure your application to where that isn't true).

It's something I want to clean up in Laravel itself, but the auth part is a real rat's nest honestly.

For example Auth::login() isn't actually part of the underlying interface and is again taken from a concrete class (SessionGuard), but if you have a non-stateful Guard this would blow up at runtime.

[AbyssWaIker]

I'm very glad to hear that.

As much as laravel in need of clean up with reporting thing not actually happening under the hood I'm thinking that by 0.8 (when I'm gonna be trying to use phpantom for my work) it would be much easier for me to define all the lies in the config of phpantom than to ask my colleagues to change the way they are using auth()->user() in PHPStorm and/or update all of our dependencies, ahead of schedule, lol.

And I think that a lot of people may be in a similar position when using/promoting phpantom by 1.0

P.S. And fixed an example for future reference. Thank you for your patience with my (pretty obvious) oversight, lol