Split Laravel blueprint and project codebase -> declarative programming

[misog]

Hi, Laravel Blueprint will overwrite files which were manually modified when build. How about splitting Laravel Blueprint code from project code?

For example, draft.yaml would not generate Models/Offer.php but it would instead generate a trait Models/OfferBlueprint.php with properties such as $fillable, $casts and relationship methods. Then it would modify Offer.php to include the trait:

class Offer extends Model
{
    use OfferBlueprint; // this would be added as the first trait by Laravel Blueprint
    use HasFactory; // this is Laravel default, should be removed from here if draft.yaml generates a Factory
}

Then I could modify and implement changes in Offer.php and always erase and build Laravel Blueprint. Similarly for factories and other files. Of course, migrations should have "append only" strategy and be overwritten only if forced with ex. --fresh-migrations.

Traits are better than parent classes for this, because parent classes would interfere with project code architecture. Also, Laravel Blueprint could not modify any project classes such as Models/Offer.php and interconnecting it could be responsibility of a programmer. Or, there could be a separate commands for this: php artisan blueprint:plug and php artisan blueprint:unplug which would deal just with adding/removing traits in project models, project factories, etc.

How powerful declarative programming tool can be build?

[jasonmccreary]

Thanks, but Blueprint is all about conventions. In addition, it generates pretty standard code. So abstracting basic properties and methods away in a trait breaks that.