Generate cleaner model mixin classes

[georgeboot]

Summary

1. removed @mixin from mixin itself when using mixin mode

The generated mixin class, contained a @mixin phpdoc to itself. This breaks phpstan as it's a recursive reference.

2. don't add extends and implements to generated class when using mixin mode

If you are using mixin mode, the mixin only needs to contain the properties and methods. The mixin does not need to extend the models classes, as the model already does that and the helper annotations are mixed in.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update
• Misc. change (internal, infrastructure, maintenance, etc.)

Checklist

• Existing tests have been adapted and/or new tests have been added
• Add a CHANGELOG.md entry
• Update the README.md
• Code style has been fixed via composer fix-style

[mfn]

Not 110% sure about the effect but happy to give it a try 😄

[georgeboot]

Not 110% sure about the effect but happy to give it a try 😄

We're using it atm and works like charm :)

[edcoreweb]

@mfn @georgeboot I added the write_mixin feature initially, and unfortunately this breaks auto-complete on builder methods such as firstOrFail, find, etc.

To fix this, you need to add extends \Eloquent back or replace it with @mixin \Eloquent

laravel-ide-helper/src/Console/ModelsCommand.php

Line 996 in 3ba1e25

$output .= "extends \Eloquent ";

Or to add the @mixin \Eloquent this needs to be modified.

laravel-ide-helper/src/Console/ModelsCommand.php

Line 927 in 3ba1e25

if ($this->write && !$phpdoc->getTagsByName('mixin')) {

[georgeboot]

Are you sure about that?

A static analyser should combine the data from the mixing with the data inferred from the class itself (hence the name mixin). Practically this means that this package should only min-in attributes, relations and other magic methods into the existing definition, which should already contain findOrFail etc.

[edcoreweb]

@georgeboot I am pretty sure.

findOrFail is a method on the Illuminate\Database\Eloquent\Builder not on Illuminate\Database\Eloquent\Model, so it's not available unless you extend \Eloquent or mix that in.

The package already mixes in Illuminate\Database\Eloquent\Builder and Illuminate\Database\Query\Builder into a new facade, \Eloquent

See the config file.

[georgeboot]

Ah now I see what you mean. I personally always use MyModel::query()..... so haven't noticed this.

Maybe related: didn't Laravel 9 change things related to the multiple types of query builders and their relation to model classes?

[edcoreweb]

Not that I am aware of, they added some dummy interfaces for the Builder and QueryBuilder classes to assist with code completion, but those only come into play if you do Model::query()->findOrFail and not Model::findOrFail

IMHO this introduced a breaking change, and it needs to be fixed.