Filament Addons Laravel Package

Getting Started

This is a collection, not a library — orientation comes before installation. Read README.md's addon index top-to-bottom first; it is the only enumeration of what ships and how each piece registers. Then skim src/ — the directory layout mirrors the addon names and doubles as a table of contents.

Confirm the compatibility matrix before writing a line of code:

composer show filament/filament | grep versions      # v2 vs v3 — not interchangeable
cat vendor/bezhanSalleh/filament-addons/composer.json # actual requires, not the changelog
php -v                                                # Laravel 10 implies PHP 8.1+

Then install and pin:

composer require bezhansalleh/filament-addons:^1.0

1.0.1 is the release that widens Laravel 10 support (PR #7). If you're on Laravel 9, 1.0.0/1.0.1 both serve you; don't expedite a framework bump to chase this package. If you were blocked on Laravel 10 by this dependency, sequence 1.0.1 ahead of the framework upgrade so each change is independently bisectable.

Register in the PanelProvider that needs it — never in AppServiceProvider, and never globally, or you'll leak admin UI onto customer-facing panels:

public function panel(Panel $panel): Panel
{
    return $panel
        ->plugins([
            // only the addons this panel actually uses
        ]);
}

Publish only what the specific addon's README says is required, then clear caches:

php artisan vendor:publish --tag=filament-addons-config
php artisan vendor:publish --tag=filament-addons-assets
php artisan optimize:clear

First use case: pick the smallest addon, wire it into a non-production panel, confirm the page renders under php artisan serve. Because unrelated components ship together, one install is effectively several feature evaluations running in parallel — do them one at a time so a failure is attributable.

Implementation Patterns

Per-addon, per-panel adoption. Treat each addon as a discrete adopt/defer/skip decision. Roll out one addon per PR, scoped to a single non-production panel, with a render assertion. The consumed surface stays small enough that forking is a day's work.

Config-driven enablement. Commit the published config so behavioral defaults are reviewable in diffs and can't drift silently under a minor bump. This also gives you a natural kill switch per addon.

Inline component use. The form fields and table columns are used exactly where native Filament components are — inside resource form()/table() schemas. If an addon is registered on the panel, its components are available anywhere in that panel: resources, pages, widgets, actions. That's the "composable" promise, and it's where the day-to-day value is: a one-line replacement for a custom formatter or layout tweak.

Multi-panel standardization. Because registration is panel-scoped and config-driven, multiple panels in one app can share a consistent set of building blocks without forcing every panel to carry the whole collection. This is the cleanest way to use the package: standardize a core, opt the rest out.

Smoke-test each enabled addon. One assertion per addon that the panel page renders. Admin screens have the weakest test coverage in most apps, and the failure modes here (missing asset, missing config, wrong Filament major) surface as rendering failures.

Upgrade cycle. composer update inside the existing constraint, php artisan optimize:clear, run the admin smoke path. There are no migrations and no expected config republication, so the change is genuinely trivial — but the smoke test is what distinguishes an ordinary update from an incident.

Fork-readiness hygiene. Pin ^1.0, review each release note (they're short — mostly Dependabot plus compatibility PRs), and keep the enabled list short enough that vendoring it is a bounded task. Note the repo's release cadence as a standing risk item rather than discovering a Filament major gap reactively.

Gotchas and Tips

• Filament v2 addons do not run on v3 panels (and vice versa). Check composer.json constraints locally — the changelog does not state this, and it will not warn you at install time in every case.
• Global registration is the classic footgun. Filament addons are panel-scoped. Registering in a shared provider leaks components into every panel, including ones you never intended.
• Publish tags are per-addon. filament-addons-config / filament-addons-assets may not be the exact tag for the piece you want — read the addon's README section before assuming a single publish command covers it.
• Silent breakage from a registered-but-unpublished addon typically manifests as a rendering failure, not an exception. When a panel page goes blank, check asset/config publishing before you debug the class.
• Cache is the usual suspect. After any publish or registration change, php artisan optimize:clear; if the panel is component-cached, rebuild that too. Half the "it didn't update" reports are stale caches.
• Config drift under a minor bump. Publish and commit config so defaults can't change out from under you mid-upgrade. If a behavior changes after composer update, diff the published config first.
• Debugging path: rendered HTML → src/<AddonName>/ (class, config keys, Blade/asset dependencies) → config/filament-addons.php after publishing. The source tree is small enough that reading it is faster than guessing.
• Extension points: the Blade views are publishable for layout overrides, and the component classes are ordinary Filament components — subclass or wrap them rather than patching vendor. This is what keeps the fork option cheap.
• Don't assume Laravel 11+. Support has arrived via drive-by contributions, not a maintainer roadmap. Verify against composer.json before any framework upgrade; treat an unpinned constraint resolving to an untested combination as a foreseeable failure.
• Tier-2 dependency. Volunteer-maintained, no SLA, abbreviated changelog. Fine for admin surfaces where failure is inconvenient; don't build core revenue workflows on it without owning the upgrade path.