Filament Selectify Laravel Package

Technical Evaluation

Architecture fit. andrewdwallo/filament-selectify remains a presentation-layer plugin for Filament forms. It does not touch persistence, authorization, or domain logic — it swaps the default Select rendering for segmented toggle/radio-style controls that bind to the same underlying state path. Architecturally "shallow," which is what you want from a UI convenience package: no migrations, no model concerns, no service container churn. The v3.0.0 release does not change this — it changes which Filament major the package tracks. The release splits the package into two explicit compatibility lines: v2.x for Filament v3, v3.0.0 for Filament v4. That is now the dominant factor in fit. If our admin surface is Filament v3-era, the relevant artifact is still v2.0.9 and v3.0.0 is a non-event for us. If we are on or moving to Filament v4, the package just cleared its single biggest adoption blocker.

Integration feasibility. Unchanged mechanically: composer require, field-level usage, optional panel-provider registration, asset/view publishing if we run a custom Tailwind theme. Fields extend Filament's own field classes, so validation, ->required(), ->reactive(), ->live(), ->afterStateUpdated(), and relationship semantics are inherited. Effort is hours, not sprints. The real cost remains standardization, not installation. What changes is the constraint on the install step: the version we pin is now determined by our Filament major, not by "latest."

Technical risk.

• Version coupling (still highest risk, but reshaped). Previously the risk was "a future Filament upgrade silently breaks this." The v4 port partially retires the known instance of that risk — the maintainer has now shipped a compatibility line for the next major. The residual risk is different and arguably sharper: v3.0.0 is a fresh major delivered via a community PR (#29, first-time contributor), not a battle-tested increment. A version-compatibility port is exactly the class of change where view overrides, asset registration, and state hydration get subtly wrong. It is not a "boring" release even though the changelog is short.
• Bus factor (marginally improved). Single maintainer historically; v3.0.0 shows an external contributor landing the highest-effort change to date. That is a genuine positive signal on project health, but one merged PR is not a succession plan. Star count remains low (~47). Mitigation unchanged: MIT, small surface area, readable enough to fork and own.
• Community validation (still low, and now more relevant). The Filament v4 line has essentially no production exposure yet. We would be an early adopter on that path. On the v2.x/Filament v3 path we are no worse off than before.
• Accessibility (must be re-verified per line). A v4 port touches the Blade views and the form component internals that carry keyboard handling, focus rings, and ARIA roles. A v3 accessibility sign-off does not transfer to v3.0.0. If we have WCAG 2.2 AA obligations, the audit is per-version, not per-package.
• Scope creep perception. Unchanged and still the main reason risk is tolerable: the fallback (Select) is a one-line change and nobody is blocked by this package.

Key questions.

1. Are we on Filament v3, v4, or mid-migration today? This now decides everything: v3 → pin v2.x and treat v3.0.0 as irrelevant; v4 → v3.0.0 is the only viable line.
2. If we are moving to Filament v4, does our migration plan have a window for this package? The package's v4 support is fresh; we should land it in the same change set as the Filament upgrade, not silently afterward.
3. If we stay on Filament v3, do we accept staying on v2.x indefinitely? That line is now in maintenance-by-omission. What is our trigger to move — our Filament upgrade, or the maintainer dropping v2.x support?
4. Do we use a custom Filament theme? If so, do the package's v4 views need different Tailwind content globs than v3 (v4 reworked the asset pipeline)?
5. What is our accessibility bar (WCAG 2.2 AA?), and has the v4-rendered control passed keyboard/ARIA review — not just the v3 one?
6. Are there forms where a segmented control degrades usability — many options, long labels, i18n string length, mobile width?
7. Do we want direct field usage scattered across resources, or an internal wrapper/preset class to insulate us from a fork or replacement? (This decision is now more valuable, not less, because it lets us straddle the v2/v3 line split.)

Integration Approach

Stack fit. Requires PHP + Laravel + Filament. Zero database footprint, zero queue/worker implications, no external services. The only new consideration: the package version must match our Filament major, so the "stack fit" question is now a two-dimensional matrix (package line × Filament version) rather than a single yes/no. We should confirm the matrix against our composer.lock, not the README.

Migration path. Still nothing to migrate at the data layer; adoption remains incremental and reversible at the field level. The install step is now version-gated:

1. Determine our Filament major from composer.lock.
2. Pin the matching package line explicitly — v2.x for Filament v3, v3.0.0 for Filament v4. Do not use a floating constraint here; a floating constraint will happily pull v3.0.0 onto a v3 Filament install and break the panel.
3. Register the plugin in the target panel provider only — not globally — so we can pilot on one panel.
4. If a custom theme exists, add the package's resources/views to Tailwind content paths and publish assets, then rebuild. Re-verify the glob paths on the v4 line specifically.
5. Convert one low-risk form (e.g., settings or filter form) as a canary.
6. Roll out per-resource based on a documented rule of thumb (≤5 options, short labels, mutually exclusive).

Compatibility. Now two explicit axes plus one:

• Filament major — the primary gate; the v3.0.0 release exists precisely to satisfy this.
• Livewire version alignment — Filament v4 implies a newer Livewire; verify against our lock file.
• Context coverage — verify behavior in the contexts we actually use: modal forms, repeater/builder nested fields, wizard steps, and table filters. These exercise different mount/render lifecycles than a plain page form, and a major port is where those edge cases regress.

Sequencing.

• Now (Filament v3 shops): stay on pinned v2.0.9. Do not chase v3.0.0. Re-run the original spike only if we are changing something else about the panel. Note the package is now a tracked dependency with a known end-of-line, and add "is selectify's v2.x line still supported?" to our dependency review cadence.
• Now (Filament v4 shops or mid-migration): the v3.0.0 release unblocks adoption. Run the spike against v3.0.0 specifically — rendering, state binding, validation, and keyboard/ARIA behavior in a modal and a repeater. Screenshot-diff against plain Select. Treat a failure here as a "wait for v3.0.x" signal, not a "fork now" signal.
• Decision gate: if the spike passes, wrap the fields in our own thin App\Filament\Fields\* classes so call sites import our namespace, not the vendor's. This was already the highest-leverage decision; with a version-line split it becomes the thing that lets us swap lines without touching call sites.
• Week 3+: convert forms opportunistically as they are touched for other reasons. Do not schedule a dedicated sweep; the UX gain does not justify a project.
• Ongoing: add a Filament-upgrade checklist item: "re-verify selectify-rendered fields visually and functionally, and confirm the pinned package line matches the Filament major."

Build vs. buy. Still buy. Nothing in v3.0.0 changes the economics — if anything, a maintainer shipping a v4 port is evidence the "buy with a wrapper" posture is working. The decision remains "buy with a wrapper," now with an explicit version-line pin.

Operational Impact

Maintenance. Low steady-state, spiky at Filament upgrades — and the spike pattern has now been realized once, which is useful calibration. During any Filament v3→v4 transition window we may carry two package lines across different panels/branches; that is a coordination cost, not an engineering cost, but it belongs in the migration plan. Budget roughly a half-day of engineering attention per Filament major upgrade plus a visual QA pass. Pin the version explicitly in composer.json and let Dependabot surface changes for review rather than auto-merging — automated merging is now materially more dangerous because a Dependabot bump from v2.x to v3.0.0 would be a breaking change hidden behind a semver-looking jump.

Support. Still no commercial support, no SLA. Internal support routes through whoever owns the Filament layer. Blast radius remains a single form field — a Select fallback restores service. Document that fallback explicitly in the runbook, and add a one-line triage note: "check the pinned package version against the Filament major before debugging." That single check will resolve most future incidents faster than any code reading.

Scaling. Effectively free. Rendering is client-side HTML/CSS over Livewire-managed state; no per-request server cost beyond standard form render. The two real limits are unchanged and are design constraints, not infrastructure ones: (a) option count — segmented controls do not wrap gracefully and become unusable past ~6–8 options, especially on narrow viewports; (b) form density — many toggle groups on one screen increase visual noise and cognitive load. Codify a "when not to use" rule in our component docs.

Failure modes.

Ramp-up. Near zero for developers fluent in Filament's field API — components are used like any other field. The learning cost is judgment, not syntax: knowing when a segmented control helps (small, mutually exclusive, high-frequency choices like status or visibility) versus when it hurts (long i18n labels, many options, dense forms). Spend onboarding on a short internal pattern doc with do/don't screenshots rather than API documentation. Add one operational line to that doc: which package line we run and why.

Bottom line for the TPM. v3.0.0 is a meaningful release for the project's health — it retires the specific "will this survive the next Filament major?" objection and brings a second contributor — but it is not a drop-in upgrade. It is a compatibility fork: v2.x for Filament v3, v3.0.0 for Filament v4. The correct action is to pin deliberately against our Filament major rather than to bump. If we are on v3, do nothing and log the end-of-line. If we are on or moving to v4, this unblocks adoption — gate it on a spike against v3.0.0 that re-verifies accessibility and nested-field behavior, since those were reworked. The original evaluation score (0.935) still overstates maturity for a low-star, single-maintainer package, and the v4 line in particular has near-zero production exposure; treat it as a good bet with an explicit exit plan and a wrapper, not a platform commitment.