Filament Activitylog Laravel Package

Getting Started

This release (3.0.0) is a platform-alignment release rather than a feature release: functionally it is identical to 3.0.0-alpha1, and the meaningful delta is against the 2.x line. Before writing any code, confirm your app meets the new floor:

• PHP 8.3+ (8.2 and lower dropped)
• Laravel 12+ (Laravel 11 and lower dropped)
• Filament 4.x or 5.x (Filament 3 is no longer supported)
• Dev dependencies assume Pest 4 if you are copying the package's test setup

Minimal steps for a first use case:

1. composer require <vendor>/<package>:"^3.0" — the constraint must be ^3.0, not ^2.0; 3.x will not install on a Filament 3 app.
2. Check composer why-not <vendor>/<package> 3.0.0 first if resolution fails. In practice the blocker is almost always a transitive package still pinning filament/filament:^3.0 or laravel/framework:^11.0, not this package.
3. Publish config/migrations if the package ships them (php artisan vendor:publish --tag=<package>-config), then run php artisan migrate.
4. Register the plugin/provider in the Filament panel provider — this is the step people skip when copying from a 2.x tutorial.
5. Look first at the package's src/ service provider and its Filament plugin class: that is where config keys, navigation registration, and asset registration live, and it tells you more than the README about what is actually wired up.

The first realistic use case is dropping the package's panel resource or widget into an existing Filament panel and confirming it renders under Filament 4/5 before you customise anything.

Implementation Patterns

Upgrade path from 2.x. Treat this as a hard cutover, not a drip-feed upgrade. The correct order is: bump PHP and Laravel on a branch, upgrade Filament 3 → 4 (or straight to 5), get the app's own resources working, then install this package at ^3.0. Doing the package first means you debug two sets of breaking changes simultaneously.

Filament 4/5 API surface in your own glue code. Even though this package changed no features, your integration code almost certainly touches Filament APIs that moved in v4. The recurring ones:

• ->form() → ->schema() on resources, actions, and widgets
• form/table component namespaces consolidated under Filament\Schemas\*
• action classes relocated (Filament\Tables\Actions\* → Filament\Actions\* for the shared ones)
• Filament\Forms\Form / Filament\Tables\Table type hints replaced by the schema/infolist equivalents

If you subclass or extend a package resource, re-check every method signature against the Filament 4 docs rather than assuming a 2.x snippet still compiles.

Version-agnostic integration. If you maintain one codebase that must run on both Filament 4 and 5 during a transition window, isolate all direct Filament imports behind your own thin wrapper classes. The package supports both majors, but your app code pinning a specific Filament namespace is what breaks.

Panel registration pattern. Register the plugin inside panel() in your panel provider, and keep any package-specific config in config/<package>.php rather than inline. This is the difference between an upgrade that needs one config diff and one that needs a code archaeology session.

Testing. If your suite mirrors the package's, migrate it to Pest 4 conventions. Pest 3 → 4 is mostly PHPUnit 11/12 alignment and stricter expectations; the usual breakage is in dataset and hook syntax, plus any expect() chains relying on removed behaviour.

CI matrix. Set your matrix to php: [8.3, 8.4] × laravel: [12, 13] × filament: [4, 5] if you want to prove the dual-major support claim yourself. Otherwise rely on the package's own matrix but keep your app at one Filament major.

Gotchas and Tips

The "no changes" line is misleading. 3.0.0 having no changes from 3.0.0-alpha1 does not mean the alpha was a no-op — the breaking changes landed earlier in the alpha cycle and are summarised in the "Changes from 2.0.0" block. Read that block as the real changelog.

Silent install failures look like package bugs. A ^3.0 constraint that cannot resolve usually surfaces as a confusing Filament class-not-found or a panel that renders nothing, not a clean Composer error. Run composer why-not and composer outdated --direct before opening an issue.

Filament 5 is not "Filament 4 with a new number" for every package. Because this release was validated primarily as a 2.x → 3.x platform bump, smoke-test any customised widget or resource on your actual Filament major, not just the one the maintainer develops against.

Pest 4 is a dev-only concern. Dropping Pest 3 affects contributors and anyone copying the test bootstrap, not runtime consumers. If your app is on Pest 3, you can stay there — just don't copy fixtures from this repo's tests/ verbatim.

PHP 8.3 minimum is a real deployment risk. Distro-packaged PHP (Debian/Ubuntu LTS images, older Herd/Valet setups) frequently lags. Check your container base image and any CI runners before merging the bump — this is the most common reason a 3.0.0 upgrade sits unmerged for weeks.

Debugging rendering issues in Filament 4/5. Use php artisan filament:assets and php artisan filament:upgrade after the bump; stale published assets from a Filament 3 install are a frequent cause of "the package renders but looks broken."

Extension points. Prefer the package's published config and Filament's own extension hooks (custom resource pages, action overrides, view overrides registered in a service provider) over subclassing. Under a dual-major support policy, subclasses are the first thing that breaks on the next Filament release.

Pin the major, allow the minor. "^3.0" is right; "~3.0.0" will cost you patch fixes to Filament compatibility, which is exactly the kind of thing this package will need to ship for Filament 5.

Deprecation watch. Nothing is formally deprecated in this release, but dropping Laravel 11 and Filament 3 signals the maintainer's support window is roughly "current major + next major." Expect 4.0.0 to drop Filament 4 support, and plan your own upgrade cadence accordingly.