Filament Spatie Laravel Activitylog Laravel Package

Technical Evaluation

What this package is. alexjustesen/filament-spatie-laravel-activitylog is a thin Filament plugin that surfaces records from spatie/laravel-activitylog as a Filament resource — a read-oriented admin UI over an existing, well-adopted Laravel audit-trail library. It is not itself an audit engine; it is a presentation layer. That distinction drives most of the risk profile below.

Architecture fit. Fits cleanly if we are already standardized on Filament for admin surface and Spatie Activity Log for audit capture. Because the package owns no schema and no write path, it is architecturally "shallow" — a resource, table, and filters over someone else's model. Replacing it with ~1–2 days of hand-written Filament resource code is always a viable exit. That caps downside and makes it a low-coupling dependency. If we are not on Filament, or if our audit strategy is event-sourced/custom, this package has no role.

v0.7.0 change. The substantive change is Filament v3 support (PR #52, plus a README update for v3). The remaining items are Dependabot bumps to the fetch-metadata GitHub Action — CI hygiene, not runtime code. This is a meaningful release: it moves the package's supported platform from Filament v2 to v3.

Integration feasibility. Straightforward: Composer install, register the plugin on a panel, ensure the activity_log table is migrated and populated. No service providers to wire by hand, no config surface of consequence, no data migration. Onboarding cost is measured in hours for a developer already fluent in Filament.

Technical risk.

• Pre-1.0 versioning. 0.x semver gives no compatibility promise. v0.7.0 is evidence: a Filament major-version jump shipped in a minor bump. Treat every release as potentially breaking until 1.0.
• Filament v2 support is unstated. The release notes say "Filament v3 support" but do not say whether v2 support was dropped. Given the v2→v3 API divergence, dual support in a package this small is unlikely. We must verify against composer.json constraints before adopting — this is the single most important unknown. If we are pinned to Filament v2 anywhere, v0.7.0 may be unusable or may silently constrain us.
• Bus factor. Single primary maintainer, low commit volume, one first-time contributor on the critical PR. A small, non-critical surface mitigates this, but it is a real sustainability risk.
• Scope creep risk is low. The package does little, so it can break little. Worst case is a broken admin page, not corrupted audit data — the underlying activity_log rows are written by Spatie, not by this package.

Key questions for the maintainer or our own spike.

1. Does v0.7.0 retain Filament v2 support, or is v2 now unsupported? What are the exact composer.json constraints on filament/filament, PHP, and Laravel?
2. Are there any breaking changes to published views, resource classes, or config keys we may have overridden?
3. Is there a stated support window or 1.0 roadmap, or is this expected to remain a best-effort side project?
4. Does the resource support the tenancy and authorization hooks we need (per-tenant log scoping, policy-gated visibility)?
5. For high-volume logs: are pagination, filtering, and any retention/pruning expectations documented, or do we own that?

Integration Approach

Stack fit. Requires Laravel + Filament v3 (post-v0.7.0), plus spatie/laravel-activitylog as the data source. Filament v3 pins us to a modern PHP/Laravel baseline (PHP 8.1+, Laravel 10+). Confirm our platform floor before committing, since the package now inherits Filament v3's requirements.

Migration path.

• Greenfield on Filament v3: adopt directly at ^0.7. Lowest friction; no compatibility question.
• Already on Filament v2: do not take v0.7.0 blindly. Either stay on v0.6.3 (pinning the constraint) or treat the Filament v2→v3 upgrade as a separate, sequenced project. Do not conflate a panel upgrade with an audit-UI dependency bump.
• No Filament, or Filament v4+: evaluate the hand-rolled resource option. Given the small surface, this is genuinely competitive with taking the dependency.

Compatibility gating. Before merge, diff the v0.6.3 → v0.7.0 composer.json and any published assets. Check for renamed namespaces, changed view paths, or altered config keys — Filament v3 moved a lot of namespace surface, so any local overrides we have are the likely breakage point.

Sequencing.

1. Spike: install ^0.7 on a throwaway branch, register the plugin, confirm the activity list renders against real data.
2. Verify authorization/tenancy behavior against our access model — do not assume Filament defaults match our policies.
3. Confirm no local view/config overrides break; re-publish if needed.
4. Ship behind the admin panel only; no user-facing exposure.
5. Pin the constraint explicitly and add it to the dependency review queue.

Operational Impact

Maintenance. Near-zero runtime maintenance — no background jobs, no queues, no scheduled tasks, no external services. The maintenance burden is dependency-tracking: the package's release cadence is tied to Filament majors, which are infrequent but breaking. Budget a recurring review at each Filament major upgrade.

Support. Community/single-maintainer, best-effort. No SLA, no vendor. Our mitigation is the fork option: the code surface is small enough that we can vendor or reimplement in days if the project goes stale. Document that fallback so it is a known, priced option rather than a surprise.

Scaling. The risk is read-path performance, not the package. activity_log grows monotonically and quickly; an unpaginated or unfiltered admin table over millions of rows will be slow and can pressure the primary database. Confirm pagination is enforced, and plan for indexing on subject_type/subject_id, causer, and created_at. Longer term, consider retention/pruning or archiving — this is our operational responsibility, not the package's, and it is the most likely source of a production incident attributable to this integration.

Failure modes.

• Filament major upgrade → package incompatible, admin activity page breaks. Blast radius: one screen. No data loss; audit writes continue via Spatie independently.
• Package abandoned → frozen at last compatible version until fork. Blast radius: one screen, remediated by reimplementation.
• High log volume → slow page, possible DB load. Blast radius: admin UX and shared database health.
• Misconfigured authorization → unintended visibility of audit data (actor IDs, IPs, payloads) to lower-privileged admins. This is the one failure mode with genuine security weight and warrants explicit testing.

Ramp-up. A developer familiar with Filament needs well under a day to integrate and understand the package. The real learning curve is Filament v3 itself, not this plugin. No specialist knowledge required; no dedicated owner needed beyond a named maintainer for dependency reviews.

Recommendation. Adopt ^0.7 if and only if we are on Filament v3 and the composer.json review confirms our platform constraints. Treat it as a low-risk, low-value convenience dependency with a documented fork exit. If we are on Filament v2, hold at v0.6.3 and schedule the panel upgrade as its own initiative. Given the small surface area, the hand-rolled alternative remains a legitimate option worth a one-day spike before committing to the dependency.