Basically add features inspired by barryvdh/laravel-ide-helper into larastan?

[Evertt]

I've noticed that, for example, larastan can only detect whether a model has a relationship if and only if the relationship-method in question explicitly returns the relationship type.

So for example:

class User extends Model {
    public function author() {
        return $this->belongsTo(User::class);
    }
}

Will not be automatically recognized. I would need to specifically write function author(): BelongsTo in order for larastan to understand it. Now I'm guessing this has something to do with that the Reflection methods aren't able to tell you what return type can be inferred from a function? I don't know. What I do know, is that barryvdh's laravel-ide-helper does seem to be able to decipher that these methods are relationships, even when they don't explicitly define a return-type.

Now I know that barryvdh's laravel-ide-helper inspects the actual database structure and probably uses that to infer a lot of information that it otherwise couldn't.

But wouldn't it be awesome if larastan offered a similar feature? Either an executable binary in vendor/bin or an artisan command that alters all the model files to add better type annotations. Both in plain php (e.g. author(): BelongsTo) and potentially in the docblocks above those methods if it's every relevant to add like generic types for example (e.g. @returns BelongsTo<static, User> or whatever).

Because as of now, I still see that barryvdh's laravel-ide-helper solves problems that larastan doesn't solve. But I think it would simply be amazing if larastan would solve all the problems that I currently need both packages for, so that in the future I'll only need one.

[szepeviktor]

You can use Rector to add return type to your code.

[Evertt]

Okay thanks, it's great to learn about a useful tool like that. And I can see how that seems to make my point kinda moot. But it doesn't, not completely.

You see, besides the fact that barryvdh's laravel-ide-helper can determine what are model relationships without those relationships having been explicitly typed, what that package then does, is generate a bunch of docblocks (either directly in your model files, or in a separate _ide_helper_models.php file) that make these implicit relationships more explicitly typed.

And the beauty is, that you can even let the package edit the files inside of ./vendor/laravel/, for example ./vendor/laravel/framework/src/Illuminate/Database/Eloquent/Model.php. So I imagine that maybe you could even generate some helpful files inside of the ./vendor/larastan/ folder, based on a thorough evaluation of the app's models combined with checking the actual database structure, which can hopefully then somehow be used to expand the capabilities of larastan to correctly parse all of the app's (model) files with minimal effort on the developer's part.

Doesn't that seem like the dream? 😇

[calebdw]

That's a bad idea---you should not be modifing files (or creating files on the fly) inside the vendor directory. And you shouldn't really be mixing Larastan with ide-helper.

If you want better static analysis then you need to define your types.I added the return types to all our relationships with a simple Neovim macro---it's not hard to do

[Evertt]

But that doesn't solve the full problem.

For example, okay, larastan catches typos in relation names when you do TrainingDate::with('ttraining'), but for example, it does not catch the same mistake when you use withCount() instead of with(). Also in where statements, larastan is not able to determine whether the column name you're using is a valid column name. It could determine that if it had simply peaked into the database structure....

[calebdw]

See #676, Larastan needs stubs updated