Modelo Bundle Laravel Package

Getting Started

First, the framework reality: lexik/modelo-bundle is a Symfony bundle built on Doctrine ORM, not a Laravel package. It provides reusable base model classes, model managers, and behaviors (timestamps, blameable) so domain logic stays separate from Doctrine persistence. It has no service provider, no Eloquent integration, no Facade, no config publish tagging, and no package-discovery entry. composer require lexik/modelo-bundle in a Laravel app will pull Symfony and Doctrine components in, but nothing will auto-wire against Laravel's container.

The realistic paths for a Laravel developer:

1. You are not actually integrating it. The honest day-to-day answer for a Laravel-first stack is that you cannot leverage this bundle — you borrow the pattern, not the code. Skip to the next section for how that plays out.
2. You're touching a Symfony service in the same estate. Then follow the standard Symfony flow and treat the Laravel work as a completely separate concern.
3. You were asked "why can't we just use this?" Read the Gotchas section — the mismatch is structural, not cosmetic, and that answer is the most valuable output you can produce for the team.

If you actually have a Symfony app: composer require lexik/modelo-bundle (v1.0.2 pins symfony/* ^7 and needs PHP 8.2+), register Lexik\Bundle\ModeloBundle\ModeloBundle::class => ['all' => true] in config/bundles.php or let Flex do it, then look first at config/packages/lexik_modelo_bundle.yaml and the bundle's manager/base-model classes — the base model is where fields and lifecycle helpers live, and the manager is where find/persist logic lives.

First use case (Symfony side): define a domain model that extends the bundle's base model, give it its fields, and query/persist through a manager rather than through a Doctrine repository. The win is that controller/service code depends on your manager, not on EntityManagerInterface, so persistence stays swappable and boilerplate (createdAt, updatedAt, createdBy) comes for free via behaviors.

First use case (Laravel side): the equivalent is an Eloquent base model plus reusable traits. That's the translation the rest of this document is about.

Implementation Patterns

Pattern translation — this is where a Laravel developer gets real day-to-day value from the package's ideas, even without using it:

• Base model → Eloquent base class + traits. Modelo's "base model with common fields" maps cleanly onto an abstract App\Models\BaseModel that extends Illuminate\Database\Eloquent\Model and pulls in traits like HasTimestamps (though Eloquent already handles timestamps), Blameable, SoftDeletes. You are not gaining anything from the bundle here — you are gaining a structure.
• Model manager → repository / action class. Modelo's "manager" (query and persist an object without exposing Doctrine to callers) maps to Laravel repository or action classes, or to Laravel's query scopes plus form requests. If your team was going to adopt lexik/modelo-bundle for the manager abstraction alone, the same benefit exists with a 40-line BaseRepository in Laravel — and it doesn't drag in Doctrine.
• Behaviors → traits + observers. Timestamps and blameable are already first-class in Laravel (Eloquent timestamps, creating/updating observers, blameable via a trait using auth()->id()). There is nothing to import.
• Service-container wiring → Laravel container + providers. Modelo relies on Symfony's DI compiler pass and Doctrine's EntityManager. Laravel has no equivalent hook for a bundle like this; any "bridge" you write is a bespoke adapter that reimplements the wiring the bundle was supposed to give you.

If your team maintains both Symfony and Laravel services and you genuinely need to run this in the Symfony side while consuming it from a Laravel side: put an interface in front of it. Expose the manager's read/write operations as an HTTP or message boundary; do not try to import the PHP classes into the Laravel app. The Doctrine EntityManager, bundle config, and behavior listeners will not cross the runtime boundary cleanly.

If you must evaluate it for a Symfony service you own: the correct implementation pattern is "manager in the Symfony app, controller depends on manager, entity stays a plain model extending the bundle's base." Keep the base-class inheritance shallow and wrap the manager behind your own interface so a future fork or replacement is contained.

Gotchas and Tips

• Laravel-first = not applicable. Record the framework mismatch explicitly. If someone pushes the package into a Laravel discussion, the correct response is "wrong ecosystem, evaluate Eloquent traits / a Laravel-native CRUD/config-schema package instead," not "let's try it and see." A partial bridge is a multi-week project that produces worse results than two days of writing a base model.
• The Doctrine dependency is the real blocker, not Symfony. Even a hypothetical Laravel bridge would have to reconcile Doctrine's unit-of-work with Eloquent's active-record model. Those are not the same mental model and mixing them produces subtly broken transactions.
• Symfony 7 / PHP 8.2 floor. v1.0.2 is a chore(deps) bump that adds Symfony 7 support and nothing else. If a Symfony service in your estate is on 6.4 LTS, this release is available, not urgent, and it should land in the same change window as the Symfony 6→7 upgrade, not before.
• Maintenance signal is thin. v1.0.x, single visible maintainer, releases are dependency chores. Treat it as "safe to use on peripheral plumbing, unsafe to build a roadmap on." If it ever sits on a critical path, name an owner for the eventual fork before adoption, not after.
• CI coverage is unverified. A constraint bump with no accompanying test work means Symfony 7 compatibility is declared, not proven for your PHP/Doctrine matrix. Run the bundle's tests in a branch against your real versions before committing to it.
• Behaviors are the most misjudged feature. "Timestamp and blameable" sounds like a reason to adopt, but every framework now ships this in a few lines. If that's the value proposition pulling the package in, build the ten lines and drop the dependency.
• Debugging: if a Symfony service mysteriously breaks after the bump, check composer why-not symfony/framework-bundle first — a still-6.x bundle elsewhere in the graph is the most likely near-term failure, and it surfaces as a Composer resolution error, not a runtime bug.
• Where the package is actually good: base models + managers + behaviors on a small, low-blast-radius Symfony 7 app where the team already lives in Symfony. That is genuine boilerplate reduction. It is not a bridge, and it will not help a Laravel codebase.