Filament Json Laravel Package

Getting Started

This release (v3.0.0) is primarily a compatibility release: it adds support for Filament 5 and Laravel 13. There are no new user-facing features documented in the notes, so treat v3 as an upgrade milestone rather than something to explore for new capability.

Where to look first, in order:

1. composer.json of the package — check the require block before doing anything else. A v3 major bump almost certainly tightened constraints, e.g. php: ^8.4, laravel/framework: ^13.0, filament/filament: ^5.0. Confirm your app satisfies all of them before running composer update, otherwise you will fight the solver for an hour.
2. CHANGELOG.md / upgrade guide — the release note is one line, but a major version bump implies removed/renamed APIs. Look for a UPGRADE.md or a "3.0" section in the changelog.
3. config/*.php in the package — diff it against your published copy in config/. Config keys renamed or removed between majors are the single most common cause of silent misbehaviour after an upgrade.
4. Service provider / plugin class — confirm how it registers itself into a Filament panel in v5 (->plugin(...) in the panel provider is the standard path).

First use case: get the package bootstrapped into a single Filament panel, hit one page in the browser, and confirm assets resolve. That one smoke test exercises registration, config, views, and the asset pipeline at once — the four things most likely to break on a Filament major.

composer require vendor/package:^3.0
php artisan vendor:publish --tag="package-config"   # check the tag in the provider
php artisan filament:upgrade
php artisan optimize:clear

Then register it in your panel provider:

public function panel(Panel $panel): Panel
{
    return $panel
        ->default()
        ->id('admin')
        ->plugin(\Vendor\Package\PackagePlugin::make());
}

Implementation Patterns

Upgrade as a staged branch, not in place. Because this is a major with two framework bumps behind it, do the work on a branch and upgrade in this order: PHP → Laravel 13 → Filament 5 → this package. Upgrading the package first means every error you hit has ambiguous ownership.

Pin the pair, not just the package. The compatibility claim is only meaningful as a tuple. Record it in composer.json explicitly so future-you knows the tested combination:

"require": {
    "php": "^8.4",
    "laravel/framework": "^13.0",
    "filament/filament": "^5.0",
    "vendor/package": "^3.0"
}

Register per-panel, not globally. Filament plugins are panel-scoped. If you run multiple panels (e.g. admin and app), register the plugin only where it belongs, and use panel-level config overrides rather than editing the global config file. This keeps a single package instance serving differently-configured panels without duplication.

Configuration via config() at boot, not at runtime. Filament 5 panels are increasingly cached (php artisan filament:cache-components, php artisan optimize). Anything read from config during a request can drift from what was cached at build time. Read config in the plugin's register()/boot() and pass resolved values into components, so config:cache in production produces the same behaviour you saw locally.

Wrap it behind your own thin layer. If you are using the package on more than a couple of resources, add a small base class or trait in your app (e.g. App\Filament\Concerns\UsesPackage) that applies the package's defaults. When v4 inevitably renames something, you patch one file instead of forty resources. This is cheap insurance and the single highest-leverage pattern for third-party Filament plugins.

Keep the asset build in CI. Filament 5 continues the trend of shipping compiled assets that must match the installed version. Add php artisan filament:assets (or filament:upgrade) as an explicit CI/deploy step rather than relying on someone running it locally, or you get stale-CSS-in-production bugs that are maddening to diagnose.

Gotchas and Tips

• The release note is thin — verify the actual constraint. "Filament 5/Laravel 13 support" does not tell you whether Filament 4 is also still supported, or whether Laravel 12 was dropped. Read composer.json's require block; do not infer a minimum from the note. If it says ^5.0 only, your v2 install is now a dead end on Filament 4 and you need a coordinated upgrade.
• Major version, so assume breakage. A v3.0.0 that only adds framework support still signals "we took the opportunity to clean up." Grep your codebase for direct references to the package's namespaces, config keys, view names (vendor::...), blade component aliases, and published migrations before upgrading. These are the usual casualties.
• Published views and migrations are yours now. If you ran vendor:publish on v2, composer update will not overwrite them, and the package will happily render your stale v2 views against v3 classes. Diff the package's resources/views against resources/views/vendor/ after upgrading and re-publish deliberately.
• config:cache hides config drift. After a major upgrade, always run php artisan optimize:clear before concluding a setting is ignored. A cached config from v2 with removed keys is a classic false-positive.
• Filament 5 asset/registration changes. If the panel loads but the package's components are unstyled or its plugin features are inert, the cause is nearly always (a) plugin not registered on that panel, or (b) compiled assets not rebuilt for v5. Check both before reading package source.
• Watch the PHP floor. Laravel 13 and Filament 5 will typically require PHP 8.4+. Confirm your local, CI, and production runtimes all match — a local-only upgrade produces a green build and a broken deploy.
• Debugging strategy: bisect the panel. Register the plugin on an otherwise empty Filament panel in a scratch panel provider. If it works there and not in your real panel, the problem is panel config ordering or a conflicting plugin, not the package.
• Extension points to prefer. Use the plugin object and its ->configureUsing()/config-override surface rather than subclassing package classes. Subclassing couples you to internals that majors are free to change; configuration surfaces are usually preserved.
• Pin exact minor versions in production (^3.0 is fine for the lockfile, but note the resolved version in your deploy notes). Freshly-published majors accumulate patch releases quickly, and knowing exactly what you shipped saves time when a regression appears.

Bottom line: v3.0.0 is an infrastructure upgrade, not a feature release. Budget it as a coordinated Laravel 13 + Filament 5 migration on a branch, verify the actual composer.json constraints, re-publish stale config/views, and wrap the package behind your own base class so the next major costs you one file instead of forty.