Filament Extendable Laravel Package

Getting Started

quix-labs/filament-extendable is a Filament plugin for injecting components into existing Filament schemas (forms, layouts, groups) without editing the original class. It is pre-1.0 (v0.0.1-alpha.5), so treat the API as unstable.

Minimal path:

1. composer require quix-labs/filament-extendable:0.0.1-alpha.5 — pin the exact alpha; do not use ^0.0.1 if you value reproducible deploys.
2. Register the plugin in your panel provider (->plugin(QuixLabs\FilamentExtendable\FilamentExtendablePlugin::make())) and run php artisan filament:upgrade / clear cached panel components.
3. Look first at the package's src/ for the extension registry and the README example that inserts a component into a group — that is the canonical first use case.
4. First use case to try: add a custom field or view into an existing form's Group/Section (e.g. append a "Notes" field to a third-party resource form) and confirm it renders on create and edit pages.

If you only need static, in-repo customisation, stick with Filament's native schema composition and skip this package entirely — the value is in extending schemas you don't own.

Implementation Patterns

• Registry-style extension: define your extensions in a service provider or a dedicated Extensions/ directory, registering them once at boot rather than inside resource classes. Keeps the injection declarative and testable.
• Target by component key, not by class instance: resolve the group/section you want to extend via the identifier the package exposes; class-based matching breaks the moment an upstream package refactors.
• Ordering and priority: when multiple extensions target the same group, make insertion order explicit (priority/->sort() argument) instead of relying on registration order — boot order differs between console, queue, and HTTP contexts.
• Pair with Filament resources: use extensions for cross-cutting additions (audit fields, tenant selectors, feature-flagged fields) that must appear on many resources; keep resource-specific fields in the resource itself.
• Feature-flag at the extension level: wrap registration in if (Feature::active(...)) so you can disable an injected field without redeploying schema code.
• Testing: assert on the rendered Livewire form component (assertFormFieldExists) after booting the panel in your test case; extension registration happens in the panel bootstrapper, so a bare unit test won't see it.

Gotchas and Tips

• Alpha churn: 0.0.1-alpha.x releases can and do break the registration API between patches. Read the diff, not just the changelog line, before bumping. Pin the exact version in composer.json.
• OOM on group insertion (fixed in alpha.5): prior alphas could exhaust memory when inserting components into a group — typically a recursion/duplication loop where an injected component re-triggered extension resolution. If you are on alpha.4 or earlier and see Allowed memory size exhausted during form render or filament:cache-components, upgrade. If the symptom persists on alpha.5, look for an extension whose target group is a descendant of the component it injects — that self-reference is the usual culprit.
• Recursion guard: never let an extension target a group that contains the extension's own output. Add an explicit exclusion or a static "already applied" flag in your registrar.
• Caching: Filament caches panel components. After changing extensions run php artisan filament:clear-cached-components (and optimize:clear in CI) or you'll debug a ghost.
• Duplicate registration: service providers that boot twice (e.g. under Octane or in tests with multiple panel bootstraps) can insert the same component twice. Guard registration with a once/static flag.
• Performance: every injected component is a Livewire-rendered node. Batch related fields into a single custom component/view rather than registering many small ones.
• Extension point worth knowing: the package's public registry is the intended escape hatch — prefer composing your own extension class over patching vendor code, so the next alpha bump is a composer update rather than a merge conflict.
• Debugging: dump the resolved schema (->getComponents() on the container) in a tinker/test to see what actually got injected and in what order, rather than inferring from the browser.