Doctrine Auditable Bundle Laravel Package

Technical Evaluation

Architecture fit: still poor as stated, but the Symfony/Doctrine framing is now materially stronger. The 5.0.0 release does not change what this package is — a Symfony bundle with a DI extension, a configuration tree, and Doctrine event subscribers — so the reframing from the prior assessment stands: this is a Symfony/Doctrine candidate, not a Laravel package. What changed is that the underlying framework coupling got deeper, not shallower. "Auditable configuration is evaluated at cache warming stage instead of runtime" means the bundle's compiler pass is now load-bearing: configuration is resolved during container compilation, not on demand. Any integration path that bypasses Symfony's container build (i.e., hand-bootstrapping the bundle inside laravel-doctrine/orm) would now get no auditable configuration at all rather than late-bound config. The prior assessment's core objection — "we would be consuming it in a mode its maintainers never tested" — is upgraded from a caution to a near-blocker for the Laravel path. If the target application is Laravel/Eloquent, this remains out of scope; evaluate owen-it/laravel-auditing instead.

Integration feasibility: improved for Symfony, unchanged-to-worse for anything else. Attribute-based ORM mapping is the single most important line in the release notes. The prior assessment flagged "if only annotations are supported and Doctrine 3 is in play, the package is effectively dead on arrival" — that specific DOA risk is retired for the mapping-metadata layer. Symfony 6 support and PHP 8.0 minimum are table stakes rather than differentiators. The friction points from the prior assessment survive untouched: the blame resolver is almost certainly still bound to Symfony's TokenStorageInterface and needs a shim; audit-entity persistence still needs a dedicated EntityManager or explicit listener exclusion to avoid recursion. One new friction point: the final keyword on classes "not intended for inheritance" constrains our mitigation strategy (see Operational Impact).

Technical risk: high, but the risk profile has shifted from "abandoned artifact" to "narrowly-scoped artifact."

• Staleness — downgraded. A release exists, a named external contributor (@edefimov) is credited, and Symfony 6 / PHP 8 / attribute mapping were addressed. This is evidence the repo is not dead. It is not evidence of cadence: a single jump release after a long dormancy, with no published support matrix, is a one-off maintenance event, not a track record. Treat as "barely maintained" rather than "unmaintained."
• Adoption signal — unchanged. The release notes carry no accompanying adoption evidence. Low stars, no dependents, no third-party validation. Still no vendor, no SLA, no CVE triage expectation.
• ORM version coverage — still the top open risk. Symfony 6 support and attribute mappings are consistent with Doctrine ORM 2.9+ / 2.x. The release notes say nothing about ORM 3.x, which removed the annotation driver and tightened the event API surface. Attribute support is necessary but not sufficient for ORM 3. This is now the highest-value unanswered question in the whole evaluation.
• onFlush fragility — unchanged. Nothing in the notes touches change-set capture. Collection deltas, insert-then-update within a flush, inverse-side-only changes, and DQL/raw-SQL bypass are all still live failure surfaces.
• Blame correctness — unchanged. Async/console/impersonation attribution is still unresolved by the release.
• Breaking-change surface — new. "Classes not intended for inheritance are made final" is a deliberate API-narrowing change. It is defensible upstream, but it directly removes our cheapest remediation lever (subclass and override the listener to patch a capture gap), which matters given we expect to fix behavior.

Key questions for the maintainer/sponsor: Which Doctrine ORM versions are supported and exercised in CI — is ORM 3.x in scope, or is this ORM 2.x only? Is Symfony 6 an addition or a replacement — are Symfony 4.4/5.x still supported, and what is the support policy for the prior major? Does the cache-warming configuration change mean config is now compile-time only, with no runtime override path? Which classes are now final, and is the change-set listener among them? Does it capture collection/association changes and hard deletes, or only scalar field diffs? Where is the blame resolver bound, and can it be overridden without subclassing a final class? Is the audit write inside the domain transaction or a separate EntityManager? Is there retention, partitioning, or pruning tooling? Is there a read-side API, and what is the storage format (serialized PHP vs JSON)?

Integration Approach

Stack fit. Only pursue if the target is a Symfony 6+ application on Doctrine ORM 2.x, or a Laravel application already committed to laravel-doctrine/orm and willing to run a compiled Symfony container to satisfy the config tree. The cache-warming change makes the second case substantially harder than the prior assessment implied; assume it is not viable until proven otherwise. Eloquent-based applications: stop, discard.

Migration path. If replacing gedmo/doctrine-extensions Loggable, the mapping migration is now simpler on the annotation side — attribute-based metadata is supported, so @Gedmo\Loggable becomes this package's auditable attribute without an annotation-driver dependency. The audit schema is unchanged by this release: table shape and payload encoding still differ, so historical rows still do not carry over. Dual-write window or one-time backfill with an explicit source discriminator, as before. Versioned-entity revert remains a feature to verify explicitly — the release notes give no reason to believe revert tooling was added.

Compatibility. PHP 8.0 minimum means PHP 7.x targets are now excluded outright — if any application in the estate is still on 7.4, this release severs it. Confirm PHP 8.2/8.3 behavior specifically, since CI coverage is unknown even though the floor moved. Confirm ORM 3.x status before pinning anything. Because 5.0.0 is a major, assume the upgrade is not drop-in for existing consumers.

Sequencing.

1. Spike (2–3 days): one aggregate root end to end — create, update, association change, delete, DQL bulk update — to measure actual change-set fidelity. Unchanged from the prior plan and still the highest-information step.
2. Resolve the ORM 3.x question before the spike concludes. If ORM 3 is unsupported and our roadmap includes it, the package's usable life is bounded by our upgrade window and the fork/vendor decision changes character.
3. Resolve the blame/actor abstraction behind an interface we own, so Symfony security does not leak into domain code.
4. Fork and vendor the package into our repo. Note the new constraint: with classes now final, remediation means patching upstream source in the fork, not subclassing. Plan the fork as a maintained patch set with a diff we can reapply on upstream bumps.
5. Expand to remaining aggregates; add a conformance test suite asserting audit-row shape per mutation type.
6. Retrofit retention and read-side tooling, which the package still will not provide.

Operational Impact

Maintenance. Still fork-on-adopt, and the 5.0.0 changes make the fork slightly more expensive: final classes force source patching over extension, and the cache-warming configuration path means our fork must keep the compiler pass coherent with any container changes we make. The maintenance case is better than assessed — upstream is not abandoned — but ownership still sits with us. Do not schedule this as a normal Composer dependency.

Support. No vendor, no SLA, no issue-triage expectation. The credit to @edefimov is weak evidence that external contributions are accepted; it is not a commitment to review ours, and it does not create an escalation path. Escalation remains "we fix it." The one thing that changed is that fixing it is now marginally more constrained by the final markers.

Scaling. Unchanged. Write amplification: every flush mutating an audited entity doubles or more the write set plus per-entity serialization cost — measure on batch-import paths before enabling broadly. Unbounded growth: no natural ceiling; expect time-based partitioning or archival within the first year and index (entity_class, entity_id, created_at). Also confirm audit writes share the domain transaction — atomicity is usually what we want, but a failed audit insert then rolls back a legitimate business write.

Failure modes. (1) Silent gaps from DQL/raw-SQL mutations and bulk operations — mitigate by convention plus a query-level lint. (2) Infinite recursion if the audit entity itself becomes audited. (3) Memory pressure on large flushes, since the listener materializes change sets for the whole UnitOfWork. (4) Missing or misattributed actor in async/console contexts. (5) Payload format drift if serialization strategy changes without a schema version field. (6) New: config-resolution failure or silent default-behavior at cache warmup if the container compilation path is customized or bypassed — the failure now surfaces at deploy time rather than first audit write, which is better for detection but harder to work around.

Ramp-up. Low conceptual cost — onFlush auditing is well-trodden — but the real ramp is reading the listener source to know precisely what it does and does not capture. Budget one engineer, roughly a week, to reach confident ownership including the conformance suite. Add a half-day for the 5.0.0 delta: attribute mapping, the cache-warming config path, and cataloguing which classes we would need to un-final in the fork.

Recommendation. Do not adopt as a dependency. The 5.0.0 release meaningfully improves the picture — attribute mappings, Symfony 6, PHP 8, and evidence the project is not abandoned — and it retires the "dead on arrival" concern on mapping metadata. It does not touch the two things that drive the decision: unbounded onFlush edge cases and total absence of adoption/support signal. Evaluate as a reference implementation for an in-house listener, or fork-and-vendor, only if the target stack is Symfony 6+/Doctrine 2.x and ORM 3.x is not on the near roadmap. If the target stack is Laravel/Eloquent, discard and evaluate owen-it/laravel-auditing.