withTrashed() on relations

[MatthesSt]

Is there any reason why the morphTo relation is the only relation which type includes the withTrashed() scope even though all relations can apply the scope

[nirav-gajera]

@MatthesSt i don't think there is any specific reason why MorphTo should be the only relation type that includes withTrashed() in its type definition.

withTrashed() works fine with other relations too, as long as the related model uses SoftDeletes. eg.:

public function user(): BelongsTo
{
    return $this->belongsTo(User::class)->withTrashed();
}

the issue seems to be only with the type definitions / IDE support. laravel handles it correctly at runtime, but static analysis tools don't know that withTrashed() is available on relations like BelongsTo, HasOne, etc.

maybe MorphTo got this support added separately because of its dynamic nature, but the other relationship types could probably benefit from the same typing updates.

[nirav-gajera]

i looked into this a bit more, and I think the reason is related to how MorphTo works internally

MorphTo is different from other relationships because Laravel does not know the related model class when the relationship is defined:

return $this->morphTo();

the actual model (Post, Video, etc.) is only resolved at runtime. Because of this, MorphTo has its own withTrashed(), withoutTrashed(), and onlyTrashed() methods to store and apply those scopes after the related model is resolved.

example, this needs special handling:

public function commentable(): MorphTo
{
    return $this->morphTo()->withTrashed();
}

because Laravel does not know yet which model it will query.

for normal relationships like BelongsTo:

public function user(): BelongsTo
{
    return $this->belongsTo(User::class);
}

the related model is already known (User), so Laravel can apply the SoftDeletes scope through the normal Eloquent query builder flow. There is no need for BelongsTo itself to define a withTrashed() method

so I think this is not a missing feature in other relationships, but rather a special requirement for MorphTo because of its dynamic nature

The reason it appears in MorphTo's type definition while not appearing in BelongsTo, HasOne, etc. is because MorphTo has to handle this case explicitly.