Drop In Action Laravel Package

Technical Evaluation

Verdict for decision-making: this is a ~150-line Filament v2 form-schema component, not a platform. The TPM decision is not "should we adopt a framework" but "do we take a small, unmaintained, zero-cost dependency for one UI affordance, or spend roughly a day owning it." Frame it at that granularity and it stays proportional.

Architecture fit. It fits exactly one situation: a Filament v2 admin panel where a secondary action (send test, apply template, archive with reason) must live inside a form schema next to the field it acts on, rather than in a table row or page header. It does not fit anywhere else. Despite the name, it is not a Blade drop-in and has no publishable config — it is a schema component. If the panel is Filament v3+, native Filament\Forms\Components\Actions supersedes it and the correct decision is no dependency at all. Filament major version is a hard gate, checked before anything else.

Integration feasibility. High. One composer require and one entry in a ->schema([...]) array. Real effort is hours, not weeks. The deliverable that matters is not the integration but the single wrapper class that every schema calls, so that migration or vendoring is a one-file change later.

Technical risk. The risk profile is migration debt, not runtime failure. Signals: single author, 86 stars, zero dependents, 0.x version line, last release May 2023 (a cosmetic x-dynamic-component change from a first-time contributor — evidence of triage, not of a roadmap). The v0.2.2 change couples the package to Filament's view-resolution internals, which is precisely the coupling that makes framework upgrades expensive. Secondary risks: actions may not see the parent form's unsaved state; nested modal forms inside a Livewire-rendered form can produce validation-scoping and state weirdness; the package has no authorization logic of its own and delegates entirely to Filament's pipeline, so any auth gap is one we wrote.

Key questions to answer before greenlight:

• What Filament major version are we on today, and what is the upgrade horizon for that panel?
• Does the candidate action need the surrounding form's live, dirty values? (Validate in a spike — do not assume.)
• Is the surface internal/back-office, or customer-facing or security-sensitive?
• Who owns the wrapper class, and what is the exit trigger?
• Do we have a policy position on community Filament plugins, or does this set one by precedent?

Integration Approach

Stack fit. Laravel/PHP with Filament v2. No migrations, no config, no queue or infra footprint, no runtime services. It is presentation-only glue over Filament's existing Action API, which means everything a Filament action can do (confirmations, modal forms, notifications) is available inside it — that API is the real leverage, not the package.

Migration path. Adopt on the explicit assumption that this is short-lived. Two viable paths:

• Depend: pin the exact tag 0.2.2, never a caret range — 0.x semver permits breaking changes on minor bumps, and a routine composer update is a bad way to discover that.
• Vendor: copy the class and Blade view into app/Filament/Components/ with MIT attribution. Roughly half a day including tests, gives immediate control over PHP 8.3/Laravel 11 compatibility, and turns removal into a one-line refactor.

Either way, schemas should reference our wrapper, never the vendor FQCN. The eventual v3 migration is a deletion ticket, not a port: DropInAction::make()->actions([...]) maps almost one-to-one onto native v3 actions.

Compatibility. Gate on composer show filament/forms before any code. Verify the FQCN and the filament/forms constraint directly in vendor/awcodes/drop-in-action/ — there is no documentation beyond a changelog and a package description, so source-reading is the only reliable check. If the panel ships heavy theme customisation or custom action view overrides, re-verify they still resolve; the dynamic-component resolution path fails silently, not loudly.

Sequencing.

1. Version gate (blocks everything).
2. One throwaway spike validating the two known sharp edges: does the action see unsaved parent form state, and does a modal-form-in-form behave.
3. Wrapper class merged with a Livewire page test asserting render and authorization-conditional visibility.
4. One internal screen as pilot — the canonical "form is the unit of work" case.
5. Expand only after the pilot holds, and cap the number of schemas using it.

Do not let adoption spread ahead of the spike. The blast radius is the thing you control.

Operational Impact

Maintenance. Assume we own it. There is no maintainer SLA and bus factor is 1; the code is small enough that ownership cost is low, but it is still a line item, and it belongs in the dependency register with an owner name against it.

Support. No docs means our wrapper's docblock is the docs. If the wrapper is the only exposed API, a Filament-fluent developer ramps in about an hour; without it, every schema is an independent discovery exercise. Support tickets in this area will be UX tickets ("the button didn't do what I expected"), not package bugs — which means the action handler design, not the component, absorbs most of the support load.

Scaling. Runtime scaling is a non-issue. The scaling concern is adoption scaling: every additional schema increases the cost of the eventual v3 migration and the number of files touched by a package swap. Cap it deliberately, and prefer grouping related actions into a single slot over scattering components.

Failure modes and mitigations.

• Unsaved parent state unavailable to the action — spike first; if the workflow needs it, redesign the screen rather than fight the component.
• Nested modal form validation and state scoping — simplify the modal schema when it appears; patching the vendor is almost never the fix.
• Silent theme/view regression from dynamic resolution — verify in the pilot's visual review, not in production.
• Authorization gaps — visible() is presentation only; enforcement belongs in the handler behind a policy. Make this a code-review checklist item.

Ramp-up. One developer, roughly one sprint-day for gate + spike + wrapper + pilot; half a day if we vendor. Small enough to fit inside an existing sprint without a planning ceremony.

Policy signal. This is a clean test case for whether we adopt community Filament plugins freely or require vendoring for anything we depend on. Recommended rule: internal, low-blast-radius surfaces may take pinned community dependencies behind a wrapper; customer-facing or security-sensitive surfaces require vendoring or in-house build. Write the removal ticket at adoption time, with an agreed trigger — wrapper not shipped in the first sprint, or the package blocks a Filament upgrade — so the exit decision is pre-made rather than renegotiated under pressure.