Caleb White

I'm fairly certain this is (or rather should be) mixing in the root Redis class/client from phpredis and not the alias: https://github.com/laravel/framework/blob/5710fdb8bf36df501405c705f7d2ea4720d2b9d3/src/Illuminate/Redis/Connections/Connection.php#L18-L23 There's no reason for a class to mixin...

Note that this is also just testing an unknown class on alias mixin---this is not testing the specific code that caused the segfault: https://github.com/larastan/larastan/issues/1883#issuecomment-1999647373

What is a valid use case for this and what does the config look like?

@lancepioch, Given the following config: ```php return [ // ... 'enum' => [ 'driver' => 'session', 'provider' => App\ProviderEnum::Users, ], ], 'providers' => [ 'users' => [ 'driver' => 'eloquent',...

Where else in the code are the `providers` keys used? To my understanding, it is only referenced in the guard `provider` definition---and the guard name does not have to match...

Interesting, but what use-case are you trying to fix / solve here? Is there an error that you where getting that led to this change?

Okay---to test you would need to create a custom scope that implements the generics and then assert the types. Also note that this should work with custom builders that are...

A custom Builder of the form: ```php /** @extends Builder */ class AnnouncementBuilder extends Builder { // ... } ``` is not generic and would break your code. A custom...

This test should be good enough: tests/Type/data/custom-eloquent-scope.php ```php

Nice! Though I'm not sure that Larastan would be able to understand which connection that migration should go under since it's hidden behind a method call and then a config...