- What is laravel-enso/history-tracker used for?
- It is a small Laravel package that records create, update, and delete events on Eloquent models into a history table, giving applications an audit trail. It is designed for the Laravel Enso ecosystem, where the admin interface can display a model's change timeline. Outside Enso it works as a thin audit-log implementation with a small feature surface.
- How do I install laravel-enso/history-tracker?
- Install it with Composer, publish and run the migration, add the trait to the models you want to track, and ensure an authenticated-user resolver is available. Validate dependency resolution against your Laravel and PHP versions before committing, because the package is archived and its constraints are likely outdated. Also confirm that your database engine supports the JSON diff column.
- Does laravel-enso/history-tracker support the latest Laravel versions?
- The package is archived, so it almost certainly does not declare support for newer Laravel majors and PHP releases. Check its composer.json constraints and test install-and-boot in a scratch branch against your actual versions. A failed dependency resolution is a realistic outcome and would block adoption immediately.
- Is laravel-enso/history-tracker still maintained?
- No. The upstream repository is archived, which means no security patches, bug fixes, or framework upgrades. With roughly 51 stars there is effectively no community and the bus factor is near one. Any defect you encounter becomes your responsibility to fix.
- Can I use laravel-enso/history-tracker outside of Laravel Enso?
- Only with extra work. It inherits Enso conventions for the user model and namespace layout, so outside Enso it is essentially a thin audit-log trait plus a migration. For a mainstream Laravel stack, maintained alternatives are the lower-risk choice. If you specifically need the Enso UI timeline, adopting and forking under the MIT license is the realistic route.
- What alternatives exist to laravel-enso/history-tracker?
- For event-level logging, spatie/laravel-activitylog is broadly adopted and actively maintained. If you need field-level diffs and retention hooks, owen-it/laravel-auditing is the usual choice. Both are lower-risk defaults than forking an archived package.
- Does history-tracker store dirty attributes or full model snapshots?
- The package records changes to Eloquent models, but you should confirm in the source whether it stores only dirty attributes or full snapshots. This matters for audit usefulness and for how much data you retain over time. The stored diff uses a JSON column, so verify support on your target database engine.
- Does it record who made a change, including queued jobs and console commands?
- It relies on an authenticated-user resolver, so HTTP requests with a logged-in user are the straightforward case. Queued jobs, console commands, and impersonated sessions need explicit verification, because actor identity may be missing or misleading there. Test these paths before treating the history as a reliable compliance artifact.
- Is history written synchronously, and what happens if the audit write fails?
- Audit writes are typically synchronous within the business transaction, so treat history persistence as part of the write path. You need to know whether a failed history insert rolls back or breaks the underlying model change. Decide deliberately whether audit failure should fail the business operation, and test that behavior in your environment.
- What should I consider before using it in a compliance or audit trail?
- Treat an archived writer in an audit or compliance path as a control weakness, not just a maintenance nuisance. Decide whether the history is a compliance artifact with retention and immutability requirements, or a convenience feature for administrators. If it is compliance-relevant, prefer a maintained alternative or fork with CI, tests, and pinned versions.