Doctrine Extensions Bundle Laravel Package

Product Decisions This Supports

• Dependency triage and scope correction — the first decision this unlocks. This is not a Laravel package; it is a Symfony bundle (a fork of stof/doctrine-extensions-bundle). It ships no service provider, no publishable config, no Eloquent integration — only Symfony DI/HttpKernel bundle wiring around Gedmo's Doctrine event subscribers. If the target app is Laravel/Eloquent (the likely case given the framing), the PM action is to close the request as mis-specified and redirect it, not to schedule integration work. That single ruling saves the sprint.
• Build vs. buy on "invisible" cross-cutting behaviors. Timestampable, Blameable, Loggable, SoftDeleteable, Sluggable, Translatable, Sortable and Tree are features every product eventually needs and no one wants to hand-roll per entity. This bundle only belongs in that decision if the stack is Symfony + Doctrine ORM; on Laravel the same decision resolves to first-party traits plus established packages.
• Audit trail and compliance roadmap feasibility. Blameable + Loggable + SoftDeleteable are the substrate for "who changed what, when" and "we don't hard-delete inside the retention window." If SOC 2 readiness, GDPR erasure-vs-retention, or enterprise procurement questionnaires are on the roadmap, this is cheaper than a bespoke audit table — but the capability comes from the underlying gedmo/doctrine-extensions library, not from this distribution.
• i18n and SEO timing. Sluggable and Translatable decide whether localized URLs and multilingual content are a config change or a schema migration. Worth naming now, because it dictates schema shape and the internationalization go/no-go date.
• Data lifecycle and recovery as a product feature. Soft deletes turn "undo," recycle bins, and admin restore into a feature instead of a support escalation, and act as an operational buffer against accidental destructive deletes.
• Taxonomy and ordering UX commitments. Tree extensions underpin category hierarchies, nested comments, and org structures; Sortable underpins drag-and-drop reordering. These are UI promises that quietly dictate ORM feasibility — make them explicitly with engineering.
• Supply-chain posture as a risk call, not a commercial one. MIT, zero license cost, zero procurement friction. The only real variable is engineering risk: 0 stars, 0 dependents, single maintainer, and a Composer name (mkietlinski/doctrine-extensions-bundle) that doesn't match the repo name (StofDoctrineExtensionsBundle) — which makes fork-vs-upstream auditing harder than it should be.
• A signal about documentation debt. A Symfony bundle filed against a Laravel codebase usually means the architecture doc is stale or teams are mixing stacks. That's a small tech-radar correction, not a backlog item.

When to Consider This Package

• Only after confirming the stack is Symfony + Doctrine ORM. If the app is Laravel/Eloquent, do not consider it — close the ticket. If the app is Laravel with laravel-doctrine/orm, depend on gedmo/doctrine-extensions directly and register subscribers in a service provider; the bundle layer is inert and should be dropped from the dependency list.
• Only as a considered fork, never as a default. Default to upstream stof/doctrine-extensions-bundle. Adopt this fork only if:
  • Upstream is unmaintained or broken against your pinned Symfony/Doctrine versions, and this fork carries the specific fix you need.
  • You can verify the diff against upstream and the delta is small, reviewed, and auditable.
  • A named internal owner will take the fork in-house if the maintainer disappears.
• When the behavior set is genuinely needed and load-bearing. Not on speculation: adding Translatable before there's a real localization requirement imports schema complexity for a roadmap item that may never ship.
• Look elsewhere when:
  • You are not on Doctrine ORM (Eloquent, raw DBAL, API Platform with custom persistence) — the extensions are entity-lifecycle bound and won't carry over.
  • Tables are large or write-heavy and Tree/NestedSet or Translatable query patterns need benchmarking first — these are convenient, not free, and retrofitting is a migration.
  • You need vendor SLAs, security-patch guarantees, or a support contract. A single-maintainer, zero-adoption fork cannot supply any of that.
• Do not adopt without a version-compatibility check. Gedmo is tightly coupled to Doctrine ORM internals and breaks on minor upgrades; confirm the current and next-planned Symfony/Doctrine/PHP matrix before it becomes load-bearing.

How to Pitch It (Stakeholders)

For executives. This is a free, MIT-licensed integration library — no license cost, no procurement, no vendor negotiation. It does not ship user-facing features itself; it removes engineering weeks by making standard data behaviors (audit trails, soft deletes, SEO-friendly URLs, multilingual content, sortable hierarchies) a matter of configuration instead of custom code. Two caveats dominate the recommendation. First, it is a Symfony bundle, so if our product is Laravel it delivers none of that value to us — the request is mis-specified and should be closed or redirected to Eloquent-native equivalents. Second, where Symfony is genuinely in scope, it is a single-maintainer, effectively zero-adoption fork of a well-established package. The decision there is not "spend or don't spend" but "do we accept a low-grade maintenance dependency to save engineering time now." Recommendation: standardize on upstream stof where Symfony/Doctrine is real, treat this fork as a named contingency with an internal owner and documented exit path, and take the dependency nowhere on a Laravel codebase.

For engineering. This is a Symfony bundle wiring gedmo/doctrine-extensions into the container: Timestampable, Blameable, Loggable, SoftDeleteable, Sluggable, Translatable, Sortable, Tree (NestedSet/ClosureTable/MaterializedPath), Uploadable — via entity annotations/attributes, toggleable per entity manager. Before we treat it as a candidate, please answer: (1) Is any part of the estate actually Symfony/Doctrine, or is this a Laravel ask? That one answer flips the recommendation. (2) What is the diff against stof/doctrine-extensions-bundle, what patches justify the fork, and who owns them? (3) Compatibility with our current and next Symfony/Doctrine/PHP versions, including attribute vs. annotation metadata driver. (4) Query-plan review for any Tree or Translatable usage on large tables, plus a soft-delete filter-leakage test on every API code path — that is a data-exposure class of bug, not a correctness nit. (5) A named owner for patching or forking. If any of those can't be answered, we go upstream — and on Eloquent we don't take this at all: first-party SoftDeletes/Timestampable, spatie/laravel-sluggable, spatie/laravel-translatable or astrotomic/laravel-translatable, kalnoy/nestedset, spatie/laravel-activitylog, and model observers for blameable.