Audit Bundle Laravel Package

Technical Evaluation

The stack mismatch stands, and v3.0.2 does not touch it. nti/audit-bundle remains a Symfony 3 bundle built on Doctrine ORM's onFlush event lifecycle. It has no Eloquent integration, no Laravel service provider, no facade, and no support for Laravel's model events. The "bundle" suffix is literal: it registers via Symfony's Bundle class and depends on the Symfony DI container. The new release is a one-line-scope bugfix to a console command and changes none of this.

• Architecture fit: Poor to non-existent for a Laravel codebase. The audit mechanism is a Doctrine EventSubscriber that inspects the Unit of Work's entity change sets during onFlush. Eloquent has no equivalent Unit of Work; the closest analogue is model observers plus getDirty()/getChanges(). Porting the bundle would mean reimplementing its core, not installing it.
• Integration feasibility: Zero direct. The only technically honest paths are (a) fork and rewrite the listener for Eloquent, or (b) discard the code and adopt the pattern — an audit trail written from model lifecycle hooks into a polymorphic audits table. Option (b) is what mature Laravel packages already do.
• Technical risk: High across the board, unchanged by a patch release.
  • Framework EOL: Symfony 3 reached end of life in November 2021. Nothing in the v3.0.2 notes suggests a dependency bump; the constraint should be re-read from composer.json to confirm, but a delete old logs naming fix is not a modernization signal. Any package constrained to Symfony 3 is unpatched against four-plus years of framework CVEs.
  • Adoption signal: Effectively no dependents and no evidence of production use anywhere. This is not a niche-but-solid package; it is an unvalidated one.
  • Naming confusion: "DataDogAuditBundle" is lineage from the original simplethings/datadog-audit-bundle naming, not a Datadog product. Anyone assuming vendor backing or commercial support is mistaken.
  • Bus factor: Still effectively one. v3.0.2 is a patch from a second contributor, which is mildly encouraging but is community bugfix throughput, not a maintainership commitment or a roadmap. The absence of any feature-level release in the 3.0.x line is the more telling signal.
  • What v3.0.2 actually tells us: a class-naming bug in the log-pruning command was reported and fixed. That is a healthy sign for a hobby project and an irrelevant sign for a compliance control. It does confirm the bundle has some log-retention tooling (see Operational Impact), which is a factual correction to a prior assumption rather than a change in verdict.
• Key questions to resolve before spending further time:
  1. Is our target stack actually Laravel, or is this ticket a leftover from a Symfony evaluation? The answer changes the recommendation entirely.
  2. What is the compliance driver — SOC 2 / HIPAA / internal forensics? That determines whether a generic audit table suffices or whether we need tamper-evident, append-only storage.
  3. Do we need field-level before/after diffs, or just "record X changed at time T by user U"? The former is materially harder and drives build-vs-buy.
  4. Who owns the audit subsystem long-term? An audit trail is a compliance artifact; it cannot be an unowned dependency.

Assessment: Do not adopt. The package is architecturally incompatible with the stated stack and carries EOL-framework and single-maintainer risk. v3.0.2 is a patch-level bugfix with no breaking changes, no new features, no deprecations, and no dependency movement — it does not warrant reopening the decision. Its low score remains accurate, and the elevated "opportunity" signal should be read as a lack of adoption artifact, not as market white space. An unused package is not an opportunity; it is a warning.

Integration Approach

• Stack fit: None for Laravel. For a hypothetical Symfony 5.4+/6.x codebase, the concept fits cleanly — Doctrine's change-set API is the correct interception point — but the package's own version constraints almost certainly pin it below that. The composer constraints should be verified before any further discussion; if they read symfony/symfony: ~3.0, the conversation is over. Nothing in the v3.0.2 changelog indicates that constraint moved.
• Migration path (recommended): Treat this as a requirements input, not a dependency. Extract the design intent — capture insert/update/delete with actor, timestamp, entity identity, and changed-field diff — and satisfy it with a maintained Laravel-native package. The realistic shortlist:
  • owen-it/laravel-auditing — closest functional match, Eloquent-native, field-level diffs, mature.
  • spatie/laravel-activitylog — lighter, better if the need is activity feed rather than compliance-grade change history.
  • Roll-your-own observer + audits table — justified only if you need custom retention, partitioning, or tamper-evidence that off-the-shelf packages don't provide.
• Compatibility: Even the concept port needs care. Doctrine exposes a full change set per flush, giving transactional batching for free. Eloquent fires per-model, so a naive port produces N audit writes per request and must be wrapped in a transaction or queued to avoid write amplification. This is the single largest semantic gap between the source package and any Laravel equivalent — budget for it explicitly.
• Sequencing:
  1. Confirm the stack and the compliance driver (see questions above). One day.
  2. Spike the leading Laravel-native candidate against our two or three hairiest models — soft deletes, polymorphic relations, JSON columns. Three to five days.
  3. Decide build vs. buy based on the spike's gaps, not on this package's feature list.
  4. Only if buy fails, fork this repo for reference implementation of the diff algorithm. MIT license makes that legally clean.
• Do not schedule integration work for the bundle itself. There is no version of this that lands in a Laravel service container without a rewrite that exceeds the cost of the alternative.

Operational Impact

• Maintenance: Adopting means forking, and forking means permanent ownership. You inherit Symfony 3 EOL exposure, PHP version drift, and any Doctrine ORM API changes the listener touches. There is no maintainer roadmap and no escalation path. The MIT license is the package's only real asset here — it permits the fork, but it does not reduce the cost of it.
• Support: Effectively none. No issue-tracker community of scale, no Stack Overflow corpus, no third-party tutorials, and no one else to discover the sharp edges. v3.0.2 shows someone other than the original author can land a fix, which is a marginal improvement over zero, but a single patch from a single contributor is not a support model. For a compliance subsystem, that is the worst possible support profile — auditors ask who maintains the control, and "a fork of an abandoned bundle" is a difficult answer.
• Scaling: Audit tables are append-only and grow superlinearly relative to business tables. Expect the audit schema to dwarf the primary schema within a year. The bundle ships a log-deletion console command — v3.0.2 was a fix to its class naming — so basic retention tooling exists, which corrects a prior assumption. That is still only a delete-by-age job: there is no partitioning, no archival tier, and no async write path, and every business write becomes at least two writes in the same transaction. On hot tables this means measurable latency regression and lock contention, and the audit table becomes the throughput ceiling. Plan for time-based partitioning and a tested retention/archival job from day one, regardless of which package you choose.
• Failure modes to design against:
  • Audit failure breaks the business write. A listener throwing inside onFlush aborts the transaction. Decide explicitly whether audit is fail-open (lose the log, keep the write) or fail-closed (block the write). Compliance usually demands fail-closed; performance usually demands the opposite. This is a product decision, not a coding one.
  • Recursive auditing — an audit entity that is itself audited. Guard against it.
  • Schema drift. When a source entity gains a column, the audit representation must absorb it without migration churn. Verify the diff format is schema-agnostic (JSON blob) rather than column-mirrored.
  • PII in the audit log. Audit logs are the classic GDPR right-to-erasure blind spot — you can delete the user but the history of their changes persists. Redaction and retention policy must be designed before the first row is written, not retrofitted. Note that a pruning command is a deletion control, not a redaction control; the two are not interchangeable in a data-subject request.
  • Silent gaps. No alerting on audit-write failure means you discover the hole during an audit. Instrument it.
• Ramp-up: Negative ROI. Time spent teaching a Laravel team Symfony's DI container, bundle registration, and Doctrine's Unit of Work is time not spent shipping. A Laravel-native alternative needs hours, not weeks, and the knowledge transfers to the rest of the codebase.

Bottom line for the roadmap: Reject nti/audit-bundle as a dependency. v3.0.2 is a maintenance patch on a dead-end branch and does not change the recommendation. Re-scope the ticket as "select or build an audit trail for Laravel," run the short spike, and pick from the maintained options. The bundle's only durable contribution is a reminder of the requirements — actor, timestamp, entity, diff, and now retention — which any competent alternative satisfies.