Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Filament Activitylog Laravel Package

swisnl/filament-activitylog

A Filament plugin for viewing and managing activity logs powered by spatie/laravel-activitylog. Quickly browse logged events with causer and subject details, filter records, and use ready-made, customizable resource and table views to add audit trails directly to your Filament admin panel.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Platform upgrade sequencing. 3.0.0 is a compatibility release, not a feature release. Its real signal is that the package's supported matrix has moved to PHP 8.3+, Laravel 12+, and Filament 4/5. That makes this a dependency-driven input into your own upgrade roadmap: if you plan to move the admin surface to Filament 4 or 5, this package is ready; if you are still on Laravel 10/11 or PHP 8.2, adopting 3.x forces an application upgrade first.
  • Build vs. buy for admin/panel functionality. Filament 4 and 5 support in a single major line indicates the maintainer is tracking Filament's release cadence rather than lagging a version behind. That lowers the "we'll end up maintaining a fork" risk that usually tips a build-vs-buy decision toward building in-house.
  • Forward-compatibility bets. Explicit Filament 5 support means a greenfield build on Filament 5 can standardize on this package today instead of deferring the decision or writing a temporary shim.
  • Migration scoping. The 2.0.0 → 3.0.0 delta is entirely platform floor changes plus a dev-tooling bump (Pest 4). There are no new features to sell internally and no data/schema migration implied by the notes — so the cost estimate is "upgrade the host stack," not "rework integrations."
  • Version-pinning strategy. Because 2.x remains the correct choice for Laravel ≤11 / PHP ≤8.2 estates, this supports a deliberate split: keep 2.x pinned on legacy apps, adopt 3.x only on the modernized stack. Avoid a single shared version constraint across a mixed-version portfolio.

When to Consider This Package

Adopt when all of the following hold:

  • The application is on Laravel 12+ and PHP 8.3+ (or is committed to getting there within the current planning horizon).
  • The admin/panel layer is on Filament 4 or 5, or is scheduled to be.
  • You want a maintained third-party integration rather than owning custom Filament components, and you can accept a third-party dependency in a user-facing surface.
  • You are starting fresh (Filament 5) or already mid-migration — the 3.0.0 release removes the "will this be ready in time?" blocker.

Look elsewhere or stay on 2.x when:

  • You are pinned to Laravel 11 or lower or PHP 8.2 or lower with no funded upgrade. Do not adopt 3.x; it will not install.
  • You need a long-support / low-churn dependency and cannot absorb a major-version bump each time Filament ships one. This package's release history suggests majors track Filament majors.
  • The functionality is small enough that a handful of in-house Filament components is cheaper than a dependency plus upgrade overhead.
  • You require a published support window or SLA — the notes give no LTS commitment, and a "no changes from 3.0.0-alpha1" final release means the alpha period was the stabilization window; validate that in your own environment before committing.
  • You are mid-freeze on a release train: this is a breaking major with zero functional upside, so defer unless it unblocks a Filament upgrade.

Verification items before sign-off (the release notes alone are insufficient): package identity and maintainer activity, test coverage against Filament 4 and 5 (dual support often hides untested paths), documented upgrade guide for 2.x → 3.x, and whether 2.x will continue receiving security fixes.

How to Pitch It (Stakeholders)

To executives: This is a maintenance release that keeps a third-party admin-panel dependency aligned with our target stack. It adds no features and carries no licensing or cost change. Its value is risk reduction — the vendor is actively tracking Filament 4 and 5, so we are not adopting a component that will strand us a version behind. The trade-off is a hard floor: it requires PHP 8.3+ and Laravel 12+, so it is only adoptable after our platform upgrade, not before. Recommend: treat it as a downstream task on the existing upgrade roadmap, not a standalone initiative.

To engineering: 3.0.0 is functionally identical to 3.0.0-alpha1 — treat the alpha as the stabilization period and validate in staging rather than assuming a quiet final release means a quiet upgrade. Breaking changes are exclusively platform floors (PHP ≥8.3, Laravel ≥12) plus a Pest 4 dev-dependency bump; there is no application-code migration implied by the notes. Two actions: (1) confirm our Filament target version and whether we need dual 4/5 support in the same codebase, testing both paths since dual-version support commonly leaves one path under-tested; (2) keep legacy apps pinned to 2.x and confirm with the maintainer that 2.x still receives security patches for the duration of our migration window. Do not bundle this into an unrelated release — it should ride alongside, or after, the framework upgrade.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
shitoudev/permissionmanager
johannesclimacus/laravel-tui
hocvt/seotools
vitalybaev/sypexgeo
amphibee/themosis-ignition
gito-me/fast-excel
frankyso/laravel-ipaymu
geolize-studio/laravel-chile
boomerangui/chat
jinas/dhivatar
store-doc/laravel-storage-driver
plus-it/laravel-translation-manager
diephp/perhaps
diephp/telegraph
osmaviation/spreadsheet
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console