Class Illuminate\Database\Eloquent\Model use a missing dependency

[alepieser]

Laravel Version

12.7.2

PHP Version

8.4

Database Driver & Version

No response

Description

Hello,

On different projects, we are using eloquent as standalone package.
Everything was working well since the release v12.6.0.

Since the version v12.7.x, the class Model is using a new trait coming from the package illuminate/http.

However this package is no part of the package required by database package.

Could you please add illuminate/http as required package into composer file ?

Steps To Reproduce

Just check the composer file & the line 20 of class Illuminate\Database\Eloquent\Model

[adriansuter]

Hi, I can confirm this.

[macropay-solutions]

use Illuminate\Http\Resources\TransformsToResource;

Can all these traits be configurable via mixins? What if one chosses to not use resources from Laravel? We saw other people complaining about all these default traits in model. If they are a must they should not be traits but included in the model itself. That would solve also this issue.

Laravel's habits are a rule (sadly). If the framework until now used to do something then that automatically validates that habit to be good. Guess what...

[macropay-solutions]

What do you think of putting all these traits in a App/Models/Model.php file so each user can remove the traits he does not want to use?

[shaedrich]

@macropay-solutions While you might (or might not) be right about the usefulness of certain traits, the functionality in question has its reasons why it belongs to the \Illuminate\Http\Resources namespace: Because that's where resources live. This is not Eloquent functionality. In other words: For a model to be transformed to a resource, the code in this place needs to know about both Eloquent logic and resource logic. If we turned that around, the trait would be missing Eloquent functionality. Either way, it's tricky as these things are inevitably tied to each other.

[macropay-solutions]

@shaedrich no one questions the logic here. You are right.

The only thing is that the framework forces the user to use those traits even if they are not used in fact, while using the full framework or only Eloquent alone.

For example, from all the traits the model uses:

use Concerns\HasAttributes,
Concerns\HasEvents,
Concerns\HasGlobalScopes,
Concerns\HasRelationships, // this we had to overwrite so we can solve this vulnerability/bug
Concerns\HasTimestamps, // this we overwrite with date time not timestamps
Concerns\HasUniqueIds,
Concerns\HidesAttributes,
Concerns\GuardsAttributes,
Concerns\PreventsCircularRecursion,
ForwardsCalls,
TransformsToResource; // this we don't use because we don't use resources
/** @use HasCollection<\Illuminate\Database\Eloquent\Collection<array-key, static & self>> */
use HasCollection;

In version 8 they were fewer:

use Concerns\HasAttributes,
Concerns\HasEvents,
Concerns\HasGlobalScopes,
Concerns\HasRelationships,
Concerns\HasTimestamps,
Concerns\HidesAttributes,
Concerns\GuardsAttributes,
ForwardsCalls;

Also a trait is useful when used multiple times to avoid duplicate code.
If the trait is created to be used exclusively in the model and is tightly linked with the model logic, then why complicate things?

The code from that TransformsToResource class can't be moved into the model without dependency to the http module in this case so a base model in laravel could solve these dependency issues.

<?php

namespace App\Models;

use ...

abstract class Model extends EloquentModelAlias
{
    use HasAttributes,
        HasEvents,
        HasGlobalScopes,
        HasRelationships,
        HasTimestamps,
        HasUniqueIds,
        HidesAttributes,
        GuardsAttributes,
        PreventsCircularRecursion,
        ForwardsCalls;
    /** @use HasCollection<\Illuminate\Database\Eloquent\Collection<array-key, static & self>> */
    use HasCollection;
}

And then the project's models will extend this App\Models\Model and will give the control to the developer to use or not some traits while also removing the dependency of database to http module.

[mbabker]

will give the control to the developer to use or not some traits while also removing the dependency of database to http module

Except Laravel's not a modular framework (contrary to what the git tree split would leave you to believe) and you're really fighting against the grain if you're trying to use anything from this repository as a standalone component. Laravel wants you consuming the full stack framework, to the point that a decent chunk of the core tooling to build applications (like the entire Illuminate\Foundation namespace) is only available with the full stack download or you'd need to be aware of things like the package service providers relying on the fact the concrete Container class implements ArrayAccess but that's not an interface requirement.

I tried years ago to use parts of Laravel standalone and the longer I went with that project before life pushed me in other directions, the more it felt like I'd have been better off just building a Laravel application instead of just using Laravel's database tooling and the other resources I was using in that project.

[macropay-solutions]

@mbabker @shaedrich @adriansuter @alepieser
Sorry for any inconvenience and thank you for for your feedback.

[rodrigopedra]

This was added in PR #55107, tagging the PR for ease of search

[macropay-solutions]

@crynobone elegant solution. ;)

but https://github.com/laravel/framework/pull/55309/files#r2030628748

Update. @crynobone Good job.