Application Filament Laravel Package

Getting Started

This is a presentation adapter, not an application. Expect it to contain Filament resources, pages, widgets, and a service provider that binds them to your panel — and to depend on a sibling core package (something like liberusoftware/application or a module-application package) for the actual domain model. Read the composer.json first: it will tell you the exact Filament major version and which sibling modules must exist before this one will boot.

Minimal setup:

composer require liberusoftware/application-filament

Because the package has no tagged releases on Packagist worth trusting (last release dated in the future, zero dependents, NOASSERTION license), prefer an explicit VCS or path repository with a pinned commit:

{
  "repositories": [
    { "type": "vcs", "url": "https://github.com/liberusoftware/module-application-filament" }
  ],
  "require": {
    "liberusoftware/application-filament": "dev-main#<commit-sha>"
  }
}

Then, in order:

1. Find the service provider. Look in src/Providers/ — there will be one named after the module. Register it in bootstrap/providers.php (Laravel 11+) or config/app.php. If the package follows nwidart/laravel-modules conventions, it may instead be auto-discovered via modules_statuses.json; check module.json for a providers key.
2. Register the panel plugin or resource path. Most Liberu-style adapters expose either a Filament Plugin contract implementation or a discoverResources() path. Search the source for Panel, Plugin, or ->resources([ to see which pattern this one uses. Wire it into your AdminPanelProvider.
3. Publish anything publishable. php artisan vendor:publish --provider="Liberu\ApplicationFilament\...ServiceProvider" and check for config, views, and migrations. Migrations here are a red flag — this package should not own schema.

First use case: boot the admin panel and confirm the Application resource appears in navigation. That single smoke test tells you whether the provider registered, whether the core domain dependency resolved, and whether your Filament version matches. If the resource is missing, the problem is almost always provider registration or a Filament major-version mismatch, not the resource code itself.

Implementation Patterns

Treat it as a thin layer over the core module. The healthy pattern is: Filament resource → form/table schema → calls into a core application service or repository. If you find business rules, pricing logic, or state machines inside the resource classes, don't build on top of them — wrap the core services directly and let the adapter provide only UI.

Panel registration via plugin. The cleanest integration is to have the module ship a Filament plugin and add it to your panel:

public function panel(Panel $panel): Panel
{
    return $panel
        ->plugin(\Liberu\ApplicationFilament\ApplicationFilamentPlugin::make())
        ->navigationGroups(['Application']);
}

If no plugin class exists, register resources explicitly in your panel provider rather than relying on global discovery — it keeps the dependency visible and lets you disable the module per-panel.

Multi-panel and tenancy. Liberu projects typically run an admin panel plus a customer-facing panel. Check whether the resources declare protected static ?string $tenantOwnershipRelationshipName or implement isScopedToTenant(). If the module predates your tenancy setup, you will need to override the resource getEloquentQuery() in a subclass rather than editing vendor code — subclass the resource, register the subclass, and leave the original unregistered.

Extension points to prefer, in order:

1. Filament's own hooks — ->form(), ->table() overrides in a subclassed resource.
2. Actions and bulk actions injected from your own panel provider.
3. Macros on the module's service classes if they are macroable.
4. Only then: forking. With zero dependents and no license file, a fork is a maintainability decision you should make deliberately, not accidentally via a path repository.

Testing. Filament resources are best tested through Livewire component tests rather than HTTP feature tests:

Livewire::test(\Liberu\ApplicationFilament\Filament\Resources\ApplicationResource\Pages\ListApplications::class)
    ->assertCanSeeTableRecords($applications);

This catches the most common real-world breakage: a schema change in the core module that silently breaks a form component.

Gotchas and Tips

License is NOASSERTION — resolve this before production. There is no LICENSE file the registry could parse. That means default copyright applies: you have no granted right to redistribute or even necessarily to use it in a commercial product. Open an issue or contact the maintainer and get an explicit license (MIT/Apache-2.0) in writing. This is the single biggest blocker on this package, larger than its maturity.

Zero stars, zero dependents, one maintainer. Assume no external bug reports have been filed. Budget time to read the source end to end — it is likely small enough to do in an hour, and that hour is cheaper than debugging blind.

Release date is suspect (2026-10-26). Either the registry metadata is wrong or the tags are meaningless. Pin to a commit SHA and audit the diff before every bump. Never use a floating dev-main in a deployed environment.

Filament major-version drift is the dominant failure mode. Filament v3 → v4 changed form and table APIs substantially (Forms\Form, Tables\Table, schema unification). Check the filament/filament constraint in the package's composer.json against your app's. If it allows ^3.0 only and you are on v4, expect to patch resources — and expect those patches to be unmergeable upstream.

Provider order matters. If the adapter's provider references classes from the core application module, the core provider must boot first. Symptom: Class not found or a container binding that resolves to null in a resource's getEloquentQuery(). Fix by ordering in bootstrap/providers.php.

Navigation and authorization. Filament resources here may not define policies. If canViewAny() returns true for everyone, you will expose application data to any panel user. Audit every resource for missing authorize() calls or ->visible() conditions, and add policies in your app rather than the vendor package.

Caching traps. After any change to provider or plugin registration: php artisan filament:optimize-clear (or optimize:clear) and composer dump-autoload. Stale Filament component caches produce confusing "class does not exist" errors that have nothing to do with your code.

Migrations belong to the core module. If this package ships migrations, do not run them. They indicate the adapter is trying to own schema, which will collide with the core module's own migrations. Copy the schema intent into your app's migrations instead.

Don't let it become load-bearing. Because the package is unmaintained in practice, keep the coupling at the panel-provider boundary. If you later need to replace it, that one file plus any resource subclasses should be the entire blast radius. Write a short ADR noting the pinned SHA, the reason for the dependency, and the exit plan.