Doctrine Entity Override Bundle Laravel Package

Product Decisions This Supports

• Feature feasibility for customer-specific data model extensions. If the product ships as a Symfony/Doctrine bundle that customers or internal teams install and customize, this package answers "can a downstream app subclass and remap a vendor entity without forking the bundle?" That is a real question in multi-tenant SaaS, on-prem enterprise deployments, and white-label platforms — it shifts the answer from "fork the upstream package" to "override the entity in config."
• Build vs. buy on the override mechanism. The alternative is Doctrine's native tooling (mapped superclasses, ResolveTargetEntityListener, bundle-level mapping overrides in config/packages/doctrine.yaml). A spike against this package tells you whether it saves meaningful effort over native Doctrine configuration or is just a thin convenience wrapper — that determines build vs. depend.
• Roadmap input for extensibility/plugin architecture. If extensibility is on the roadmap (customer-defined fields, per-tenant schema variations, add-on modules), this is a reference point for what the extension contract could look like. It does not solve tenant-scoped schema isolation or runtime schema evolution, so it informs scope boundaries rather than delivering the feature.
• Vendor-risk decisions on dependency adoption. With 7 stars, 0 dependents, and a last release of October 2019, the data itself supports a "do not adopt" or "adopt with vendored fork" decision — useful as a documented, evidence-backed reason rather than a subjective veto.

Relevance caveat for the PM: despite the framing, this is not a Laravel package. It is a Symfony bundle for Doctrine ORM. It has no applicability to a Laravel/Eloquent codebase. Only act on this if you maintain a Symfony service.

When to Consider This Package

Consider it only when all of the following hold:

• You are on Symfony with Doctrine ORM (not Laravel, not Eloquent).
• You distribute a reusable bundle/library whose entities downstream applications legitimately need to extend or replace — the classic "vendor bundle, customer app overrides one entity" case.
• Entity inheritance is the right modeling choice (shared identity, shared table or joined inheritance), not merely a way to add a field.
• You have capacity to vendor the code — pin a commit, take ownership, and patch it yourself. Treat it as a source of a technique, not as a maintained dependency.

Look elsewhere — or stop — when:

• You are on Laravel. Full stop; nothing here transfers except the general concept, which Eloquent handles differently (global scopes, model swapping in service providers, custom casts).
• Maintenance risk is unacceptable. Last release 2019, 7 stars, 0 dependents means effectively no upstream support, no security response, and no compatibility guarantees with current Doctrine/Symfony majors. For a production dependency in a customer-facing product, that is disqualifying without a fork budget.
• Native Doctrine configuration suffices. Try ResolveTargetEntityListener and bundle mapping overrides first. If they cover 90% of the need, the correct decision is "don't add a dependency for a config problem," and the spike output is documentation for your own engineers.
• The real requirement is multi-tenancy or dynamic schema. Inheritance-based overrides do not give you per-tenant isolation, runtime migrations, or safe rollback. Reach for a tenant-aware schema strategy instead.
• You need a supported, current ecosystem package. Use Doctrine's own primitives; they come with the maintenance you are otherwise forgoing.

How to Pitch It (Stakeholders)

One line: A small, unmaintained (2019) MIT-licensed Symfony bundle that lets a downstream application override Doctrine entities through inheritance instead of forking the upstream bundle — technically interesting, operationally risky, and not applicable to our Laravel stack.

For executives: This is not a purchase or a build decision — it is a design reference. It shows one pattern for "customers can extend our data model without forking us," which is a recurring theme in our extensibility roadmap. Recommendation: no adoption; spend at most a short spike to see whether Doctrine's built-in entity-resolution features already cover the same ground for free. Zero cost either way, no vendor lock-in, no dependency on an unmaintained repo.

For engineering: Evaluate against ResolveTargetEntityListener and mapped superclasses before writing any code. If we do adopt, vendor it into our own namespace, pin the version, and own the maintenance — the upstream repo has no dependents and no release since 2019, so assume it is abandoned. Do not build a customer-facing extension contract on top of an unmaintained third-party bundle.

Decision requested: Approve a time-boxed (≤1 day) spike to determine whether native Doctrine configuration meets the extensibility requirement; default outcome is "no new dependency."