Static Code Analysis

[mattiamancina]

I was wondering how people are currently handling static code analysis with this package. I'm currently trying to remove larastan issues from our project, but I'm having some issues with the following code:

$model->translate('de')->name

Access to an undefined property Illuminate\Database\Eloquent\Model::$name

Am I missing something or is this not supported yet?

Was there already a discussion about using psalm templates? https://psalm.dev/docs/annotating_code/templated_annotations/#template-covariance

[Oleksandr-Moik]

As a hot fix, I can suggest using phpdoc on your model.

/**
 * @method ProductTranslation translate(?string $locale = null, bool $withFallback = false)
 * @mixin ProductTranslation
 */
class Product extends Model
{

[Oleksandr-Moik]

But can I ask you to create a simple test repository for this problem? I'll try to fix it 😌

[Oleksandr-Moik]

The option of using psalm templates is interesting, but it takes time to experiment and test...

[mattiamancina]

But can I ask you to create a simple test repository for this problem? I'll try to fix it 😌

i added a repo where larastan/phpstan produces the mentioned error: https://github.com/mattiamancina/larastan-translate

I tried your fix and it works and removes the error: ddf5e12b7d754f47ff6e84b87608b3e48ad6ba6c

Psalm templates would probably be still be a better solution tho...

[Gummibeer]

The template should be something like that - absolute pseudo not tested:

/**
 * @template TTranslationModelClass of Model
 * @property-read class-string<TTranslationModelClass> $translationModel
 */
trait Translatable {
  /**
   * @return TTranslationModelClass
   */
  public function translate(): Model {}
}

It's defining the template @template it says that the template is the value of $translationModel and that translate() returns an instance of whatever class is in TTranslationModelClass.

I'm not sure about the @property-read part and if it works. It could be that the real property has to define the template - and then it would become complicated.
Then the easier option would likely be to use @uses Translatable<ProductTranslation> as that's way easier to use for the end-users than having to do the template stuff within their own app and still have to pass down the template from the main app model down to the package trait. As templates aren't global - not even protected. Defining them in Product doesn't make them available in Translatable.

The laravel Collection class is likely a good realworld example.

And whenever we create a custom typed collection it's something like that:

/**
 * @extends Collection<array-key, Product>
 */
class ProductCollection extends Collection implements NormalizesValueObjects

[Gummibeer]

#382 is about this topic more or less - as soon as the package can pass phpstan level 6-7+ all apps should be able to use phpstan with this package without any big issues.