Filament Extras Laravel Package

Getting Started

Verify what you actually installed before assuming anything. The description is still the Laravel skeleton default ("This is my package filament-extras"), last release was 2023-04-07, and it has zero dependents. That combination means the first step is a two-minute inspection, not writing code:

composer show awcodes/filament-extras        # version, requires, autoload
cat vendor/awcodes/filament-extras/composer.json
find vendor/awcodes/filament-extras -maxdepth 2 -type d

The decisive line is the filament/filament constraint. ^2.0 means it's a Filament v2-era package and will not co-exist with a v3 panel — stop there. ^3.0 means it's worth continuing. Vague constraints (e.g. ^2.0|^3.0 with no tests) are a warning, not a green light.

Where to look next, in order:

1. vendor/awcodes/filament-extras/src/ — is there a *Plugin.php implementing Filament\Contracts\Plugin? That's a real plugin. Only a *ServiceProvider.php and *Command.php? It's a skeleton.
2. resources/ and config/ — check for publishable assets (php artisan vendor:publish --provider=... lists tags).
3. README.md — if it's still skeleton boilerplate, treat the package as source material, not a dependency.

First use case — the realistic one. If a plugin class exists, register it per-panel:

// app/Providers/Filament/AdminPanelProvider.php
public function panel(Panel $panel): Panel
{
    return $panel->plugin(FilamentExtrasPlugin::make());
}

If it's a bare skeleton, your day-one use case is different and arguably better: fork it as the starting point for your own in-house Filament plugin. The skeleton gives you the service provider, config publishing, migration stubs, and Testbench setup — the genuinely tedious parts — and you swap the placeholder namespace for your own.

Implementation Patterns

Register per panel, never globally. Filament plugins belong in the PanelProvider, not AppServiceProvider::boot(). The moment you have an admin panel and a second panel, a globally registered plugin leaks widgets, pages, and assets into both.

Wrap registration in a feature flag. Given the maintenance profile, make the package removable in one line:

->plugins(array_filter([
    config('features.extras') ? FilamentExtrasPlugin::make() : null,
]))

Treat vendor/ as read-only. If behaviour needs changing, subclass or re-register rather than patching in place — otherwise your next composer update silently reverts you. For anything non-trivial (a page, a resource, a custom field), define it in your app and let the plugin contribute configuration only.

Asset handling differs by major version. In Filament v3, plugin assets are registered via FilamentAsset::register([...]) inside the plugin's register(), then published:

php artisan filament:assets
php artisan filament:upgrade   # if migrating from v2

If views or assets look stale after an edit, clear bootstrap/cache and re-run filament:assets before debugging anything else.

Smoke-test integration immediately. One Livewire test that renders the panel login page, plus a manual hit on /admin, catches roughly 90% of plugin breakage (missing asset, bad service provider registration, namespace collision). Add it before you build anything on top of the package.

If you decide to adopt, fork first. Vendor a fork under your own org namespace, pin the Filament version, and add tests. That converts an unmaintained dependency into owned code and preserves the upstream diff for later reference.

Gotchas and Tips

• Maintenance is the headline risk. April 2023 last release, 28 stars, zero dependents. There will be no Filament v4 compatibility, no security patches, no upstream fixes. Budget for owning the source from day one — the MIT license at least makes forking clean.
• Filament v2 vs v3 is a hard wall. Confirm constraints before installing. A v2-era plugin can quietly downgrade your filament/* packages through resolver resolution. Use composer why-not awcodes/filament-extras to see conflicts rather than reading the solver output.
• Silent failures are the norm with "extras" packages. Trait- and helper-based utilities override lifecycle hooks implicitly, so breakage shows up as subtle rendering or behaviour drift, not exceptions. Pin the version and diff visually after any dependency change.
• Namespace drift when forking. Skeleton packages ship autoload entries for the original namespace. Rename the autoload mapping in composer.json, the service provider namespace, any config/view paths, and run composer dump-autoload before doing anything else — a half-renamed fork produces confusing "class not found" errors inside Filament's discovery.
• Asset and view namespace collisions. Two Filament plugins registering overlapping view namespaces or publishing to the same asset path produce missing or wrong assets. Check FilamentAsset::getAlpineComponentSrcs() / published asset dirs if styles behave oddly after adding the plugin.
• Validation is on you. With zero downstream users there's no field-tested bug surface — the first production user is you. Read the source fully; it's small enough to do that in an hour, which is the one genuine advantage of a package this size.
• Decision cost, not install cost, is the real expense. Install is minutes; proving what the package actually does and whether it's worth keeping is the work. Timebox the capability inventory to hours, spike compatibility against your exact Filament version, then gate: fork it, copy the handful of helpers you need into owned code, or reject and document the decision so it isn't re-litigated.