History Bundle Laravel Package

Technical Evaluation

Category mismatch — flag first: baskin/history-bundle is a Symfony bundle, not a Laravel package. It wraps the Gedmo/DoctrineExtensions Loggable listener with a Twig extension that renders entity change history in templates. The real auditing engine is Gedmo Loggable (a Doctrine event subscriber writing to ext_log_entries); this bundle is a thin presentation layer over it. Treat it as a UX reference implementation, not an installable dependency.

Architecture fit: Poor for a Laravel codebase. Symfony DI container + Twig vs. Laravel service providers + Blade + Eloquent. Nothing transfers except the query/render pattern. For a Symfony app already on Doctrine + Gedmo, it is a natural drop-in.

Integration feasibility:

• Symfony + Doctrine + Gedmo: low effort, ~1–2 days including ACL-scoped routes.
• Laravel + Eloquent: not usable as-is. Two paths: (a) introduce Doctrine ORM via laravel-doctrine/orm solely to obtain Gedmo — an architecture-level change unjustified by a history widget; (b) port the concept — an audit repository plus a Blade component/directive — roughly 3–5 engineer-days.
• Laravel-native alternatives: owen-it/laravel-auditing or spatie/laravel-activitylog cover ~90% of the requirement with active maintenance.

Technical risk: High / presumptive abandonware. 0 stars, 0 dependents, single maintainer, no visible CI or release cadence. Compatibility with Twig 3, Symfony 6/7, Gedmo 3.x, and PHP 8.2+ is unverified. No security disclosure path. Any defect becomes ours to own.

Key questions:

1. What PHP/Symfony/Twig/Gedmo constraint set is declared, and does it survive Symfony 7 / Gedmo 3.x?
2. Does it hydrate the data column into readable field diffs, or render raw serialized payloads?
3. Is history paginated and filterable, or does it load an entity's full log per render?
4. Is there a field allowlist, or are all changed columns exposed (PII risk)?
5. Is history scoped by tenant and viewer ACL?
6. What is the license, and is the code original or a thin wrapper?

Integration Approach

Stack fit: Not a dependency for Laravel. Use only as a design reference unless the target platform is Symfony.

Migration path (Laravel):

1. Schema: adopt an audit table modeled on ext_log_entries (action, entity type, entity id, changed-fields JSON, actor id, timestamp) or use laravel-auditing's audits table directly.
2. Capture: Eloquent observers / Auditable trait instead of Doctrine event subscribers.
3. Presentation: Blade component + view composer replicating the Twig extension's history(entity) ergonomics — timeline, field-level diff, resolved actor name.
4. Retire: do not keep Gedmo in the dependency graph unless Doctrine is already present for other domains.

Compatibility: If Doctrine already exists in the Laravel app (some teams run it for legacy bounded contexts), pin Gedmo explicitly and verify Doctrine ORM 3 / PHP 8.3 compatibility before anything else — the bundle almost certainly does not declare it.

Sequencing:

1. Spike (1 day): static Blade timeline over a synthetic audit table to validate UX and query shape.
2. Build-vs-buy review against laravel-auditing; default to buying.
3. If Doctrine is adopted, scope it to one bounded context — never app-wide.
4. Roll out per-entity, starting with the model carrying the highest compliance or support value.

Operational Impact

Maintenance: Worst-case profile — unowned code. If used, fork and vendor it, assign a named owner, and expect to carry PHP major upgrades internally. Budget 2–4 days per quarter for a production Symfony deployment.

Support: None. No maintainer SLA, no dependents generating community fixes, no CVE pipeline. Must be paired with internal security review, particularly because audit logs concentrate confidential data.

Scaling: ext_log_entries is append-only and unbounded — the dominant lifetime cost. Plan retention (12–24 months), archival or partitioning, indexes on (object_id, object_class, logged_at), and read-replica routing for history views. Estimate 1–5 KB per change and model volume before launch; blob diffs inflate storage fast. History rendering must be paginated — an unpaginated extension against a high-churn entity will take down a page.

Failure modes:

• Silent no-op: listener unregistered or entity un-annotated → empty history discovered only during an audit.
• Schema drift: entity or column renamed → older entries become undisplayable.
• Hard deletes: history orphaned or lost depending on soft-delete configuration.
• Attribution gaps: console commands, queue workers, and impersonation sessions log the wrong or no actor.
• Information disclosure: full-field diffs rendered without viewer ACL scoping.
• Serialization failures on binary, encrypted, or cast columns.

Ramp-up: Low technical complexity (small Twig helper), but non-trivial domain ramp — this is a compliance feature. Allow an engineer one day to internalize Gedmo's log schema, plus a PM/legal conversation on retention, PII exposure, and viewer entitlements. Time to production-ready: ~1 week in Symfony; 2–4 weeks for a Laravel-native rebuild.

Recommendation: Do not adopt as a Laravel dependency. Use laravel-auditing or a small in-house port modeled on this bundle's presentation layer; its only durable value is as a UX reference for rendering change history.