Entity Audit Bundle Laravel Package

Technical Evaluation

Architecture fit — unchanged, still low for a Laravel codebase. v2.1.0 is a maintenance release: a single PR merging upstream 1.23.0. It introduces no new features, no API changes, and no deprecations, and — critically — no change to the Symfony/Doctrine bootstrap surface. herdwatch/entity-audit-bundle remains a Symfony bundle built around Doctrine ORM (a downstream fork of simplethings/EntityAuditBundle), shipping a Bundle class, a DI Extension with a Configuration tree, compiler passes, and onFlush/postFlush event-subscriber wiring that writes entity diffs into shadow *_audit tables keyed by revision. None of that exists in Laravel. There is no bundle registration, no container tag system, no doctrine.orm.entity_manager alias. The only way to use it in a Laravel app is to adopt laravel-doctrine/orm and hand-rebuild the bundle's service wiring — at which point you maintain a bespoke integration of a 0-star fork. This release does not move the architecture verdict.

Integration feasibility — unchanged.

Technical risk — one risk reduced, one new observation.

• Fork divergence — partially de-risked (the substantive change in this release). The previous assessment flagged fork divergence as an unknown upgrade tax. v2.1.0 is an explicit upstream sync to simplethings/EntityAuditBundle 1.23.0, which is the first hard evidence that the fork tracks upstream rather than drifting. That converts an open question into an observed (if single-data-point) practice. It is not a commitment to cadence — one merge is not a policy — so the recommendation to pin to a commit SHA and review diffs quarterly still stands.
• Version-mapping hazard (new). The fork re-versions independently: fork v2.1.0 corresponds to upstream 1.23.0. You cannot infer upstream parity from the fork's version number. Any upgrade review must read the changelog to establish which upstream release is contained, and the vendored copy should record the upstream SHA alongside the fork tag.
• Supply chain. Still 0 stars, 0 dependents, single-vendor fork, no ecosystem validation. The release adds a first-time contributor (@maMykola) — mildly positive for bus factor, but a first contribution is not a maintained second maintainer, and a new committer on a package that touches every write path warrants the same scrutiny as any new dependency. Bus-factor is still effectively 1.
• License. LGPL-2.1 vs. the MIT/Apache norm in Laravel. Unchanged by this release; legal sign-off still required before adoption, especially for on-prem or packaged distribution.
• Blast radius. Audit writes share the business transaction — correct for compliance, but schema drift, a missing *_audit table, or a column type mismatch fails the business transaction, not just the audit trail. Unchanged.
• Performance. onFlush diff computation per persisted unit of work; unbounded revision-table growth absent partitioning/retention. Unchanged.
• Upstream content uncertainty. "Merge upstream 1.23.0" tells us the fork is current but not what 1.23.0 contains. A sync can import upstream behaviour changes (serialization of new column types, UnitOfWork interaction, schema-tool output) that are not described here. Treat the merge as a reviewable diff, not a routine bump — read the 1.22.x→1.23.0 upstream delta before absorbing it.

Key questions.

1. Is the consuming application Laravel/Eloquent, Symfony/Doctrine, or mixed? If Eloquent-only, this package should be rejected on architecture grounds regardless of version. (Unchanged — and v2.1.0 does nothing to answer it.)
2. (Reframed, partially answered.) The fork demonstrably tracks upstream as of v2.1.0. Remaining: what is the stated sync cadence and who owns it? Is the quarterly review an internal commitment we impose, or something Herdwatch has published? And what is the fork's delta against upstream 1.23.0 today — is anything custom, or is it a straight mirror?
3. What is the compliance driver — GDPR erasure, SOX, HIPAA, internal forensics? "Right to be forgotten" conflicts with immutable revision tables; needs a documented redaction strategy.
4. Does LGPL-2.1 comply with our distribution model and legal policy?
5. What is the retention window and expected audit-row volume per year?
6. Do we need revert/replay of revisions, or is read-only history sufficient?
7. (New.) Does upstream 1.23.0 carry any behaviour change relative to the 1.22.x line we would have reviewed previously — particularly in column-type serialization or schema-tool output?

Integration Approach

Stack fit. Still not a Laravel package. The correct portfolio framing remains: "Symfony/Doctrine audit bundle — relevant only to Doctrine-backed services." Scoring it against a Laravel baseline overstates its apparent relevance.

Recommended path for a Laravel product: do not integrate. v2.1.0 is housekeeping on a package that does not fit the stack; a maintenance release is not a reason to revisit an architecture decision. Adopt a native equivalent:

• owen-it/laravel-auditing (mature, MIT, Eloquent-native, active) covers ~80% of the functional surface.
• Or a thin in-house implementation: append-only audits table (auditable_type, auditable_id, event, old_values, new_values, actor_id, request_id, created_at), populated from model observers inside the same DB transaction, plus a Revision/revision_id column for grouped changesets.

The one design idea worth importing remains revision grouping: multiple entity changes in one unit of work share a revision ID, making "what happened in this request" a first-class query. Eloquent observers alone don't give you that; add it explicitly.

Recommended path if a Symfony/Doctrine service genuinely exists: the release strengthens this path slightly, because upstream currency is now evidenced rather than assumed. Still:

1. Version pin to a specific commit SHA, not a floating constraint, with a vendored fork under org ownership. Record the upstream baseline (1.23.0 as of this release) in the vendoring notes.
2. Scheduled upstream sync (quarterly) with a diff review — now a verification of a demonstrated practice rather than a mitigation for an unknown.
3. Contract tests asserting audit rows are produced for each audited entity, run in CI on every schema change — the merge is exactly the kind of event that can silently alter serialization.
4. Absorb v2.1.0 through a PR review of the upstream delta, not an automated dependency bump. Identify what 1.23.0 changed before it lands in a write path.

Migration path (if replacing an existing audit mechanism). Unchanged: inventory regulated entities → add shadow tables in a non-blocking additive migration → decide on a synthetic baseline revision for backfill → enable auditing entity-by-entity behind a config flag → dual-write for one release cycle, compare, decommission.

Compatibility. Pin PHP and Doctrine ORM minor versions explicitly. Doctrine's onFlush UnitOfWork API shifted across ORM 2.x→3.x; the release notes give no indication of supported ORM versions, so verify against your exact minor before committing. Note also that "merged upstream 1.23.0" says nothing about the fork's own compatibility matrix having been re-validated.

Sequencing. Legal/license review → architecture decision (unchanged: reject for Eloquent-only) → if adopt, pin at v2.1.0's commit + review the 1.23.0 delta + stand up the test harness → shadow schema → phased entity enablement → retention/redaction policy → observability.

Operational Impact

Maintenance. Still the dominant cost, and this release does not change the ownership arithmetic: 0 stars, 0 dependents, single-vendor fork means you are the maintainer in practice. Budget for annual license/dependency review, upstream diff review, Doctrine upgrade compatibility work, and schema migrations per newly audited entity. What v2.1.0 changes is shape: it demonstrates the fork is alive and syncing, which lowers the probability of abrupt abandonment — but a live upstream also means inbound change you must triage, so expect to consume sync releases on your own cadence rather than enjoying a static, frozen copy. Budget one review per sync as recurring cost.

Support. No vendor SLA, no issue-tracker signal (zero stars implies zero triaged issues), no Stack Overflow footprint for the fork. The new contributor is an encouraging signal but not a support channel. Internal runbooks and a named owner remain mandatory. Ramp-up for an engineer unfamiliar with Symfony bundle conventions and Doctrine's UnitOfWork is still 2–4 days to productivity and 2–3 weeks to safe production operation.

Scaling. Unchanged by this release:

• Write amplification: each audited write becomes N+1 inserts (revision row + one shadow row per changed entity) — first bottleneck at high write volume.
• Table growth: append-only revision tables typically exceed source tables within a year; without partitioning (by created_at or rev) and archival, history-query performance degrades non-linearly.
• Read path: reconstructing state at revision R needs ordered scans across shadow tables; cache or materialize "latest state" if history is surfaced in product UI.
• Transaction duration: audit inserts widen the write transaction window, increasing lock contention and deadlock probability under concurrency.

Failure modes.

Ramp-up. Plan for a one-time integration spike (1–2 weeks) to prove Doctrine-in-Laravel or a Symfony sidecar works end to end, plus the ongoing ownership cost above. v2.1.0 is a positive maintenance signal but not a functional or architectural one: if the spike is not clearly positive, the correct TPM decision remains to reject this package and standardize on an Eloquent-native auditing solution. The functional delta does not justify adopting an LGPL fork into a Laravel write path — and a version bump that changes nothing in the integration surface is not a reason to reopen that call.