Filament Icon Select Column Laravel Package

Technical Evaluation

Architecture fit. guava/filament-icon-select-column is a leaf UI dependency confined to the admin panel. It contributes one Filament table column class that both renders a stored icon value and lets an operator change it via an in-cell dropdown. It introduces no Eloquent models, migrations, seeders, queue jobs, scheduled tasks, outbound HTTP calls, environment variables, or configuration surface. There is no domain-layer coupling, so it cannot corrupt business data or sit on a customer-facing request path — the failure domain is a single table cell in a back-office screen. For a TPM this is the ideal borrow-don't-build shape: trivial integration cost, contained blast radius, and a reversal cost of one Composer line plus one array entry.

Integration feasibility. Composer install, then IconSelectColumn::make('icon')->options([...]) in the resource's columns() array, with fluent modifiers such as ->closeOnSelection() where the in-cell select interaction is wanted. Roughly an hour for an engineer fluent in Filament; half a day including QA for someone who is not. The binding constraint is not effort but version coupling: the 3.x line targets Filament v4 exclusively, 2.x targets v3. The package version is therefore not an independent variable — it is derived from our Filament major. On a v3 panel the current line is not adoptable at all, and taking it means taking the Filament v4 upgrade alongside it.

Technical risk. Low severity, poor detectability — and the release history is the evidence. 3.0.0 was a full rewrite for Filament v4; 3.0.1 exists solely to restore closeOnSelection behavior lost in that rewrite. Three planning consequences:

1. The rewrite was not behavior-parity complete on release. Undisclosed gaps may remain in render paths, keyboard navigation, or search/filter integration that nobody has filed yet.
2. This regression class is invisible to telemetry. Nothing in logs, error tracking, or CI flags a dropdown that stopped closing on selection. It surfaces as operator confusion or a support ticket, so our normal observability posture offers no protection.
3. 3.0.x should be treated as stabilizing, not stable. That is a pinning instruction, not a rejection.

Secondary risks: single-maintainer bus factor with no SLA, no security review artifacts, no accessibility conformance documentation; an effectively empty dependency graph (zero dependents) providing no evidence of production hardening; and upgrade drift if Filament ships v5 before this package follows, forcing the in-house fallback on a timeline we do not control. What makes these acceptable is that the fallback — a custom Filament column — is genuinely days, not weeks, because the component is thin.

Key questions.

• What Filament constraint does 3.0.x declare — ^4.0 or a pinned minor — and which 4.x minors are actually exercised in CI?
• Is there a published 2.x → 3.x upgrade guide, or is the rewrite's parity-gap list undisclosed?
• Is the closeOnSelection API shape unchanged from 2.x, or renamed/relocated during the rewrite? This determines whether existing code transfers.
• What automated coverage exists for the column's interaction behavior, as distinct from render output?
• Maintainer count, release cadence, and typical lag behind Filament minor releases?
• How many other Filament v4 plugins does our panel depend on, and do they have v4-compatible releases? This package is unlikely to be the only one carrying a pending rewrite, and the aggregate is what actually stalls an upgrade.
• Is our icon set static (Heroicons and similar) or dynamically/remotely sourced in a way the picker's options UX does not model?

Integration Approach

Stack fit. Laravel + Filament v4 admin panels on PHP 8.2+, and only where Filament is already the admin stack and an icon-bearing field actually exists on a resource. Zero standalone value outside that ecosystem — it should not be adopted speculatively as a "we might need it later" dependency.

Migration path. Dictated by our Filament version, not by the package:

• Already on Filament v4: install 3.0.1 directly. Do not deploy 3.0.0 — known-regressed, treat as unusable. Validate interaction behavior from scratch rather than assuming parity with whatever bespoke column it replaces.
• Still on Filament v3: treat the Filament v4 upgrade and this package's 2.x → 3.x upgrade as one coupled change in one feature branch. Sequencing them across separate merges to main will fail: the package alone violates the Composer constraint, and Filament alone strands or removes the column.

Compatibility checks. Resolve the package's declared Filament constraint against our exact pinned Filament minor; inventory every other Filament plugin in the panel for a v4-compatible release, since that aggregate is the usual cause of a stalled upgrade; rebuild and re-publish Filament assets, because v4 changed the asset pipeline and a stale build can convincingly mimic a column rendering bug.

Sequencing.

1. Inventory resources and pages using the column; separate select-in-cell usage that depends on closeOnSelection from display-only usage.
2. In one branch: Filament → v4 and package → 3.0.1.
3. Pin ~3.0.1 rather than ^3.0 until parity confidence is established. Patches may flow automatically; minors gate behind review.
4. Explicitly exercise the restored behavior: selection closes the dropdown, in both modal and full-page table contexts, including keyboard navigation.
5. Visual QA on icon rendering and on table search/filter, since the rewrite touched render paths.
6. Ship through the normal release process — no data backfill, no coordination window, no customer communications.

Operational Impact

Maintenance. Near-zero steady-state cost: no migrations, no config drift, no scheduled work, no runtime criticality. The real obligation is version watching, because this package's cadence is coupled to Filament's. Automate with Renovate or Dependabot and group Filament core plus all Filament plugins into a single dependency PR so coupled upgrades get reviewed together rather than discovered in sequence.

Support. No vendor, no SLA, no LTS branch. Support is whatever the single maintainer chooses to provide, backed by an internal owner we name explicitly. That owner is responsible for changelog review on every bump and post-upgrade verification of the column. Absent that name, the dependency is unowned and will be discovered only when it breaks.

Scaling. Not a scaling concern in any dimension — no queries added beyond the column's own attribute read, no background work, no external calls. Cost scales with the number of admin screens using it, which is a code-count concern, not a capacity one.

Failure modes. The dominant mode is silent: the column renders the wrong icon, stops closing on selection, or degrades under keyboard navigation, with nothing in logs, CI, or error tracking to flag it. Consequences are operator confusion and support tickets, not data loss, downtime, or customer-visible defects. A secondary mode is hard dependency failure at install/upgrade time — a Composer constraint conflict or an abandoned package against a future Filament major — which is loud, immediate, and recoverable via the in-house fallback.

Ramp-up. Under an hour for a Filament-fluent engineer; half a day for someone learning the table stack, QA included. The non-obvious ramp-up cost is institutional, not technical: the next engineer must know the pinned version, the coupled-upgrade rule, and the fact that 3.0.0 was a parity-incomplete rewrite. Record those three facts in a short internal note so the 3.0.0 assumption of rewrite parity isn't repeated. The closeOnSelection smoke test — modal and full-page contexts, keyboard navigation included — should be committed alongside the first adoption, not left as tribal knowledge.