Doctrine Bridge Laravel Package

Product Decisions This Supports

• Upgrade and platform roadmap planning. The bridge is versioned in lockstep with Symfony lines (6.4 LTS, 7.2/7.3/7.4, 8.0, 8.1), and each line sets a PHP floor — 8.0 requires PHP ≥ 8.4. That makes this a direct input to your hosting/runtime upgrade plan, not just a Composer bump.
• Build vs. buy (and "buy nothing"). MIT, zero license cost, maintained by the Symfony core team. The decision is never "should we build this" — it is "do we let a maintained component own our Doctrine-to-framework glue, or do we hand-roll entity user providers, uniqueness validators, and schema listeners?" Buy wins on cost and bugfix throughput.
• Architecture choices for entity-backed flows. Whether authentication resolves users from the entity store (EntityUserProvider), whether uniqueness is enforced as a validation constraint (UniqueEntity) rather than ad-hoc repository checks, and whether schema/connection lifecycle is handled by listeners instead of application code.
• Operational readiness for long-running processes. Changelog items around idle-connection closing in the idle listener and manager reset (including the v8.1.9 non-lazy-manager fix) are relevant to queue workers, Messenger consumers, and persistent-runtime deployments (RoadRunner/Octane-style setups). This is a reliability input, not a feature input.
• Migration risk register. Concrete roadmap line items live in the changelogs: AbstractDoctrineExtension deprecated in 7.4 and removed in 8.0; auto-mapping Doctrine entities to controller arguments removed in 8.0; DBAL 4.5 compatibility churn across 6.4/7.4/8.1. Any team relying on those behaviors has a dated action item.
• Dependency inventory hygiene. The bridge should never appear on a product roadmap. It belongs in the transitive-dependency register, with an owner and a version-pinning policy.
• Signal correction for stakeholders. "3.2k stars, 0 dependents" is a measurement artifact: this is a subtree split of symfony/symfony, so stars, issues, and PRs all accrue to the monorepo. Adoption should be inferred from Symfony/DoctrineBundle usage, not from this repo's counters.

When to Consider This Package

Adopt/keep it when:

• You run Symfony with DoctrineBundle — it is already installed as a transitive dependency. The real decision is version alignment with your Symfony line and clearing deprecations before the next major.
• You need specific, well-scoped integrations rather than the whole bridge: UniqueEntity validation against a Doctrine repository, entity-backed user providers for Security, Doctrine types for Uid/DayPoint/TimePoint, or schema listeners that respect schema_filter.
• You operate long-lived workers or multiple connections and want the framework-managed connection/manager reset behavior instead of custom lifecycle code.
• You are on a maintained Symfony line with a supported PHP version and want community-maintained bugfixes without headcount.

Look elsewhere when:

• You are on Laravel with Eloquent. This is a Symfony component; there is no Laravel integration story here. Pulling it in means running a second ORM and taking a Symfony Contracts dependency for marginal gain — Laravel's unique validation rule and Eloquent scopes already cover the headline use cases.
• You are on Laravel but have deliberately chosen Doctrine for a bounded domain (e.g., a reporting or legacy-schema module). Even then, evaluate the single class you need — UniqueEntity or a Uid type — against roughly a hundred lines of in-house code. Usually the in-house version wins on cognitive overhead; occasionally the bridge wins on edge cases.
• You require a vendor SLA, named support contact, or contractual roadmap influence. There is none; support runs through Symfony's community process in the symfony/symfony monorepo.
• You need API stability guarantees across majors. Behavior is dictated by Symfony and Doctrine release trains, including removals (8.0 retired AbstractDoctrineExtension and entity-to-controller-argument auto-mapping). If your product cannot absorb those breaks on the framework's schedule, isolate the dependency behind your own adapter.
• You are pinned to PHP or DBAL versions below what the maintained branches support.

How to Pitch It (Stakeholders)

To executives: This is free, MIT-licensed infrastructure maintained by the Symfony core team, and it is already in our dependency tree — we are not deciding whether to adopt it, we are deciding how to keep it current. Cost is zero licenses and zero dedicated headcount; the recurring cost is upgrade coupling, because the component's major versions move with Symfony and PHP. The changelogs show a steady, disciplined bugfix cadence across three supported release lines, which is the signal that matters for a piece of glue code.

To engineering: Treat symfony/doctrine-bridge as framework plumbing with an upgrade contract attached. Pin it to our Symfony line, track the two removals landing in 8.0 (AbstractDoctrineExtension, entity-to-controller-argument auto-mapping) and the DBAL 4.5 compatibility fixes, and verify idle-connection and manager-reset behavior under our worker runtime. Do not extend it, do not fork it, and do not add it to a Laravel service that uses Eloquent — the only defensible Laravel use is cherry-picking one class into a Doctrine-based module, and that should be justified case by case.