Doctrine Audit Bundle Laravel Package

Technical Evaluation

Architecture fit — poor for a Laravel/Eloquent stack. The package is a Symfony bundle, not a Laravel package. It hooks into Doctrine ORM lifecycle events (onFlush, postPersist, postUpdate, postRemove) via event subscribers and ships Symfony-specific wiring: a Bundle class registered in config/bundles.php, a DependencyInjection extension, a Configuration tree, and console commands. Laravel has no bundle-registration model and its default ORM is Eloquent, which emits a different event surface. As-is, the package cannot be composer required into a standard Laravel app and "just work."

Integration feasibility — conditional and high-effort. It is only viable if the target application already runs Doctrine ORM inside Laravel (e.g., via laravel-doctrine/orm). Even then, the Symfony container plumbing must be replaced with a Laravel service provider that registers the audit event subscriber on the Doctrine EventManager, binds the Auditor, and translates the bundle's YAML/XML config into Laravel config. The realistic path is extracting the core auditing logic (auditor, audit reader, audit table schema) rather than consuming the bundle wholesale — effectively a fork or re-implementation.

Technical risk — high.

• Staleness: last release 2022-02-05; no activity since. Likely pinned to Doctrine ORM 2.x and PHP 7.x/8.0. Compatibility with Doctrine ORM 3.x and PHP 8.2+ is unverified and probable breakage.
• Adoption signal: 9 stars, 0 dependents, low score (0.205). No community, no third-party validation, single-maintainer bus factor.
• Ownership transfer: adopting this means we own patching, security review, and Doctrine version tracking. There is no upstream to escalate to.

Key questions for the team:

1. Does the target app use Doctrine ORM or Eloquent? If Eloquent, this package is off the table.
2. What are the audit requirements — entity/field-level before-after diffs, actor identity, request context, retention, tamper-evidence, or regulatory (SOX/GDPR) mandates?
3. Which PHP and Doctrine versions must be supported, and does this bundle's matrix cover them?
4. Is there an internal owner willing to maintain a fork, or should we evaluate a maintained alternative (e.g., owen-it/laravel-auditing or spatie/laravel-activitylog for Eloquent; a Doctrine-native subscriber for Doctrine)?
5. What is the cost of the spike to validate extraction versus building a lightweight audit subscriber in-house?

Integration Approach

Stack fit. Two distinct scenarios must be resolved before planning:

• Pure Laravel/Eloquent: Do not integrate. Use an Eloquent-native auditing package; the effort to bridge Doctrine events to Eloquent models exceeds building a purpose-fit solution.
• Laravel + Doctrine (via laravel-doctrine/orm): Feasible via extraction. Register the bundle's audit subscriber manually on the Doctrine EventManager in an AppServiceProvider, bind the auditor as a singleton, and publish the audit schema as a Laravel migration instead of relying on the bundle's console commands.

Migration path (if Doctrine is confirmed).

1. Reconcile the bundle's audit table schema (entity, changed fields, before/after payload, actor, timestamp) with our migration tooling.
2. Port the event-subscriber registration from Symfony's DI extension into a Laravel service provider.
3. Map the bundle's Configuration options (audited entities, global ignore list, table prefix) to a config/audit.php.
4. Vendor the package (or fork) so we control patching.

Compatibility. Verify PHP 8.1/8.2/8.3 and Doctrine ORM/DBAL majors against the bundle's composer constraints. Expect to widen or patch constraints; treat Doctrine ORM 3.x support as an unknown until proven by a spike. Check database dialect support (MySQL/Postgres) and JSON/JSONB column handling for before/after payloads.

Sequencing.

1. Confirm ORM layer (decision gate — one week).
2. Compatibility spike: install in a sandbox, validate against our PHP/Doctrine versions, confirm the audit listener fires and writes correctly.
3. Evaluate maintained alternatives in parallel; compare feature coverage to requirements.
4. Decide build vs. fork vs. adopt based on spike findings and the maintenance-ownership question.
5. Only then integrate, with a test harness asserting audit correctness across create/update/delete and relation changes.

Operational Impact

Maintenance. No upstream activity since 2022. If adopted, we inherit full maintenance: security patching, Doctrine upgrade tracking, and bug fixes. Budget for a fork and a named internal owner; without that, the package is a liability rather than an asset.

Support. No vendor, no community, no dependents to lean on for troubleshooting. Incident response relies entirely on internal Doctrine expertise.

Scaling. The onFlush listener adds work to every persisting transaction, including computing field-level diffs. In high-write systems this can become a throughput bottleneck. Mitigations: async audit writes via queue, partitioned/append-only audit tables, retention and archival policies, and sampling or scoping to only sensitive entities. Plan capacity based on write volume × audited entities, not on the package's benchmarks (there are none).

Failure modes.

• Audit write failure blocking the primary transaction — availability risk; define whether audit failures should fail the request or be logged and dropped.
• Silent gaps if the subscriber is not registered on every EntityManager, or if entities are excluded by misconfiguration.
• Schema drift between the audit table and evolving domain entities.
• PII leakage — before/after payloads can capture sensitive data; requires redaction/ignore rules and access controls on the audit store.
• ORM version coupling — a Doctrine upgrade can break auditing without obvious errors.

Ramp-up. The team must learn Symfony bundle conventions, Doctrine lifecycle events, and unit-of-work semantics. Expect a moderate learning curve and a one-to-two-week onboarding for the integrating engineer, plus additional time to build confidence in audit correctness (audit logs are only valuable if provably complete and accurate).

TPM recommendation. Treat this package as a reference implementation, not a dependency. The Laravel/Doctrine mismatch, staleness, and zero-adoption profile make direct adoption high-risk. Run a short spike to extract the audit-listener pattern into an in-house subscriber (for Doctrine stacks) or select a maintained Eloquent-native auditing package (for standard Laravel), and gate any adoption on a confirmed internal maintenance owner.