Filament Multiselect Two Sides Laravel Package

Technical Evaluation

Architecture fit. Unchanged. The package remains a Filament form field — a single Field subclass rendering a dual-list (transfer) UI via Blade + Alpine.js, participating in the standard form lifecycle (state, dehydrateStateUsing, validation, afterStateUpdated). It composes inside ->schema([...]) exactly like Select::make(). No service provider wiring beyond plugin/asset registration, no persistence layer, no queue or storage surface. Friction remains near zero for any application already on Filament v3.

Integration feasibility. Still high, but the option set has changed. There are now two viable lines: the mature 2.x series (the basis of the prior assessment) and a newly published 3.0.0-alpha. Adoption remains a composer require plus asset publish, opt-in per form, with a blast radius of one component. The state-shape question — plain array vs. BelongsToMany via relationship() — is unresolved and now branch-dependent: we cannot assume the 2.x behavior carries into 3.x, and the release notes give us nothing to reason from.

Technical risk. The risk profile has materially shifted, and on balance it has improved at the strategic level while worsening at the tactical level.

1. Version drift — substantially de-risked, but replaced by pre-release churn. A 3.0.0-alpha bump is the strongest possible signal that the maintainer intends to track a new Filament major (almost certainly v4) rather than let the package lapse. That directly retires the "maintenance-only mode" concern flagged previously. The cost is that the answer to "which Filament versions are supported" is now two answers, and the forward-looking one is an alpha. We must not treat the alpha as production-ready, and we must not assume 2.x will receive further fixes now that maintainer attention has moved to a new major.
2. The release notes are uninformative — this is itself a finding. The changelog body contains exactly one entry: a Dependabot bump of two JS development dependencies. That is a CI housekeeping commit, not a feature or breaking-change description. A major-version bump with no migration notes, no breaking-change list, and no stated Filament version target means we have zero documentary evidence of what changed in the PHP API surface. Everything we need to know must come from reading the diff or a spike. For a TPM this is a governance signal: the project does not practice release communication, so our compatibility review must be source-based, not notes-based.
3. Bus factor — unchanged and now more acute. Still one maintainer, still effectively zero Packagist dependents. A solo maintainer shipping an alpha major is a normal open-source pattern, but it means the alpha's quality is bounded by one person's available time, and the stable 3.x timeline is unknown.
4. Asset pipeline — unchanged. Alpine-shipping packages require filament:assets / vendor:publish in every environment including CI and container builds. A major version may also change which assets or registration mechanism is used, so any existing deploy script assumption should be re-verified rather than inherited.

Key questions — revised, with the alpha as the center of gravity:

• New: What Filament major does 3.0.0-alpha target, and is there a published upgrade guide or breaking-change list? If not, is there at least a diff summary in the PR history?
• New: What is the intended support posture for 2.x now that a 3.x line exists — security/maintenance fixes, or frozen? This determines whether staying on 2.x is a safe holding position or a dead end.
• New: Is 3.0.0-alpha API-stable, or should we expect field method signatures to change before 3.0.0 stable? What is the rough timeline to stable?
• Does the field support relationship() for BelongsToMany, or array-only state? Has this changed in 3.x?
• Is the option list fully server-rendered, or does it support searchable/paginated/async options? What is the practical ceiling — hundreds or tens of thousands?
• How are validation messages and required state rendered against a two-list control?
• Keyboard and screen-reader behavior — WCAG-viable out of the box, or remediation required? (Worth re-testing: a major rewrite is a common moment for accessibility regressions or improvements.)
• Does it behave correctly inside Repeater, Builder, and modal-wrapped actions, where Alpine instances are cloned and destroyed?
• Is there a test suite, and does it cover the state round-trip or only the render?

Integration Approach

Stack fit. Unchanged in substance: requires Laravel + Livewire + Filament (v3 today; the 3.x line appears aimed at the next major) with Alpine.js implied. No database, cache, or queue footprint. Compatible with any stack committed to Filament; irrelevant otherwise.

Migration path. The wrapped-dependency recommendation stands and is now more valuable, not less — a wrapper is precisely what lets us absorb a 2.x→3.x transition in one file. The new decision is which line to wrap:

• Wrap 2.x — mature, matches the prior assessment's assumptions, lowest immediate risk. But potentially a line the maintainer is no longer investing in.
• Wrap 3.0.0-alpha — aligns with the maintainer's direction and the likely Filament v4 future, but puts an alpha behind a production admin surface and exposes us to API churn before stable.
• Do not take a direct dependency on either line — still rejected; it scatters an upstream namespace across resource files and forfeits the swap point.

Recommended posture: wrap 2.x if we adopt now; spike 3.0.0-alpha in parallel as a forward-compatibility probe; treat the wrapper's interface as the contract that insulates us from whichever line wins.

Compatibility.

• Pin the Filament minor version and pin this package to an explicit constraint. Do not use a floating constraint that could resolve from 2.x into a 3.x pre-release — verify the composer.json constraint on filament/filament fails loudly rather than silently resolving.
• Confirm asset publishing is in the deploy script and CI bootstrap, not a manual step, and re-confirm the mechanism against whichever major we adopt.
• Because the release notes contain no upgrade information, treat the 3.x constraint as "requires source review before any bump" in our dependency policy.

Sequencing.

1. Spike on 2.x (1–2 days), unchanged in scope. One real form; test array state, relationship state, validation, rendering inside a modal and a repeater. Answer the open questions empirically rather than from the README.

2. Add a scoped 3.0.0-alpha probe (half day). Install in a throwaway branch against our target Filament version. Goal is narrow: does it install, does the field render, does state round-trip, and how large is the API diff versus 2.x? This is an intelligence exercise, not an adoption decision.

   Note the ordering caveat: if our application is still on Filament v3, the 3.x line may not be installable at all — in which case the probe is deferred and the question becomes "what is our Filament v4 timeline?"

3. Decision gate. Adopt wrapped on 2.x if the spike passes and 2.x is confirmed as still-supported. If the 3.x probe shows a stable-looking API and 2.x is frozen, that changes the calculus toward waiting for 3.0.0 stable rather than adopting either line immediately. If relationship support or large-option performance fails on 2.x, fall back to native Select::make()->multiple()->searchable() — modest UX loss, zero dependency risk.

4. Single surface. Ship on one low-traffic internal admin resource; monitor asset loading and state persistence for one release cycle.

5. Broaden. Only after a clean cycle, and only where the transfer UX genuinely beats a multi-select (curated assignment lists, permission sets, small-to-medium candidate pools).

6. Re-evaluate at 3.0.0 stable. Re-run the probe against the stable release before any Filament v4 migration. Budget for this; do not let a Filament upgrade and a package major land in the same change.

Operational Impact

Maintenance. Low per-cycle effort, but the ownership shape has changed. Previously the annual review was a single yes/no on a new Filament major. Now we maintain awareness of two lines, a pending stable release, and a probable Filament v4 transition — and because release notes are not a reliable information source for this project, our review must include reading the source diff. Add to the budget: an explicit re-evaluation at 3.0.0 stable, and a decision record for which line we are on and why. MIT license keeps forking legally trivial; a fork remains our package to maintain and should stay a deliberate last resort.

Support. Community-only, single maintainer, no SLA, no commercial backing — unchanged. The alpha does not change support terms but does change expectations: pre-release software typically carries no stability guarantee even informally, so any 3.x adoption should be treated as "we accept API movement mid-flight." The practical escalation path remains: read the source (it is small), patch via fork or a vcs repository entry.

Scaling. Unchanged and unaffected by the release. The relevant axis is option-count, not user-count: a dual-list renders both panes, so DOM size and Alpine reactivity bind before the server does. Safely scoped to curated lists (tens to low hundreds). Not appropriate for "assign from all 50,000 users," which needs an async search-select. Server-side load is negligible.

Failure modes, ranked by likelihood:

• Silent breakage on a Filament upgrade — field renders but state fails to dehydrate, or Alpine never initializes. Unchanged and still the top risk, now compounded by a major-version transition somewhere ahead. Mitigation: pin versions, smoke test the form, keep the wrapper.
• Adopting the alpha by accident — a floating Composer constraint resolves to 3.0.0-alpha during a routine composer update, and the admin form changes behavior with no corresponding code change on our side. This is the new failure mode introduced by the release and the most likely near-term one. Mitigation: explicit narrow constraint, minimum-stability: stable for this package, and a CI check asserting the locked version.
• Missing published assets in a new environment — blank or unstyled component in staging/production but fine locally. Mitigation: asset publish in deploy script and a container build check; re-verify the mechanism if/when we move lines.
• State shape mismatch on relationship fields — selections appear saved but the pivot table is empty, or vice versa. Mitigation: assert persisted rows in a test, not just the UI.
• Cloned Alpine instances in repeaters/modals — duplicate or lost selections; a rewrite is a plausible moment for a regression here. Mitigation: spike coverage before rollout; avoid in repeaters if unproven.
• Alpha API churn — if we do adopt 3.x early, method signatures move under us between alphas. Mitigation: the wrapper class confines the damage to one file; do not adopt 3.x on more than one surface before stable.
• Accessibility gap — keyboard users cannot move items between panes. Re-test against whichever line we adopt rather than inheriting a 2.x result. Mitigation: manual keyboard test; remediate or restrict to admin-only surfaces.
• Abandonment — materially less likely given an active major bump, but note the inverse risk: 2.x being effectively frozen while 3.x is unfinished. Mitigation: wrapper class makes replacement a one-file change; the fork is small enough to absorb.

Ramp-up. Still very low for a Filament-fluent developer — well under a day, one field class with a handful of chainable methods. The organizational ramp-up grows slightly: the team now needs to know when to reach for this versus a plain multi-select, which line we are pinned to and why, and that the alpha is off-limits for production surfaces until 3.0.0 stable is evaluated. Document all three alongside the wrapper class, and record the release-notes-are-unreliable caveat so the next reviewer does not assume a quiet changelog means a quiet diff.