Filament Icon Picker Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-side icon selection. The core question this package answers: do we spend engineering time building a searchable, paginated icon-picker modal (plus table column and infolist renderers), or do we composer require one? Realistic in-house scope is 3–5 dev days for the picker plus ongoing upkeep against Filament upgrades. This package collapses that to roughly half a day of wiring, which makes "buy" the default unless we have a specific objection.
• Feature scope for "admin-configurable iconography." It unlocks a class of feature requests we currently either decline or hard-code: letting admins assign icons to categories, navigation groups, status/badge types, menu items, or tenant branding. If those requests are on the roadmap, this is the cheapest credible enabler.
• Roadmap sequencing against the Filament upgrade. The package requires Filament 5.0+, Laravel 12+, PHP 8.2+. That makes it a forcing function: adopting it either presumes we are already on Filament 5 or pushes the framework upgrade earlier than planned. That trade-off should be made explicitly, not discovered mid-sprint.
• Data-model decision: icon storage format. Because the picker persists a plain icon string (e.g. heroicon-o-star), we keep portability — the column is readable/usable without the package. The auto-generated PHP Enums are a code-side convenience layered on top, not a storage commitment. Worth recording as the intended pattern so we don't later refactor the schema.
• Icon-set curation as a product surface. allowedSets([...]) and the config file let us decide, per product area, how much choice admins get (e.g. Heroicons only for a tight, consistent look vs. all installed sets for expressive branding). That's a design-consistency decision the PM can own cheaply.
• Consistency of read vs. write surfaces. The package ships field + table column + infolist entry, so an admin-selected icon renders identically in forms, lists, and detail views. Without it we'd likely ship an inconsistent picker and a plain-text fallback in tables — a visible quality gap.
• Bundle/perf trade-off as a product decision. Icon packs are large (Phosphor ~9,000, Material ~10,000). Deciding which sets ship is a page-weight and build-time decision, not just an aesthetic one; the interactive installer and icons:cache give us a lever, but someone has to choose.
• Low ecosystem-momentum signal to weigh. 50 stars, 0 dependents, single-maintainer, MIT. That doesn't disqualify it — it's a small, narrow, replaceable UI component with a clean escape hatch (the stored value is just a string) — but it does mean we should not build anything else on top of its internals.

When to Consider This Package

Adopt when:

• We are already on (or committed to) Filament 5 / Laravel 12 / PHP 8.2+ — otherwise it's unusable today.
• Non-technical admins need to choose icons themselves, and today that means a developer ticket per icon change.
• We need more than a dozen icons and search matters — a hard-coded Select with 20 enum options stops scaling fast.
• We want one consistent icon experience across form fields, tables, and infolists, and the table/infolist renderers are genuinely useful to us (color, size, animation, fixed icons without a DB column are nice-to-haves that reduce custom Blade work).
• We're comfortable with a Blade-Icons-based approach and can accept the Tailwind @source step in our theme build.

Look elsewhere / build in-house when:

• We're on Filament 3 or 4. Waiting is cheaper than a forced framework upgrade.
• The icon vocabulary is small and stable (≤ ~30 icons). A generated enum plus a searchable Select is ~1 day of work, zero dependency risk, and better UX at that scale.
• The icon choice is developer-owned, not admin-owned. Then the picker is a nice demo, not a product need.
• Our admin panel is performance- or payload-sensitive and we can't absorb large icon bundles or a modal that loads a grid of SVGs.
• We require vendor due diligence (security review, SLA, maintained-by-org, CVE responsiveness). Single-maintainer, 0 dependents, pre-1.0-equivalent maturity means we own the fork risk.
• We need deep customization of picker behavior beyond modal size, columns, allowed sets, and search — the extension surface is deliberately small.

Middle path worth considering: adopt the display components (column/infolist entry) and the Icon::heroicon(...)-style helper while keeping icon selection restricted to a curated, generated list. That captures most of the consistency benefit with a small blast radius.

How to Pitch It (Stakeholders)

For executives (30 seconds):

Admins can't currently change an icon without filing an engineering ticket. This MIT-licensed Filament component gives us a searchable icon picker plus matching table and detail-view renderers for roughly half a day of integration instead of 3–5 days of custom build. The data it stores is a plain string, so if we ever drop the package our existing data still works — the downside is capped. The caveats are that it requires Filament 5 (so it ties to our upgrade timing) and it's a small single-maintainer open-source project, so we'd treat it as a replaceable UI dependency, not a platform bet. Recommendation: pilot it on one admin surface next sprint; two days of effort to get a real read.

For engineering:

• Install: composer require wallacemartinss/filament-icon-picker, then php artisan filament-icon-picker:install-icons (interactive) to pull only the icon sets we approve.
• Non-obvious step that will bite us: add the package views to the Filament Tailwind theme CSS via @source '../../../../vendor/wallacemartinss/filament-icon-picker/resources/views/**/*' and rebuild assets. Miss this and the modal renders unstyled.
• Optional php artisan icons:cache for runtime performance; vendor:publish --tag="filament-icon-picker-config" to centralize allowedSets.
• Enum generation is a convenience layer, not a requirement — use Icon::heroicon('users', 'outlined') if we'd rather not generate/maintain enum files.
• Risks to note in the spike: single maintainer, no dependents, Filament-5 pinning. Mitigation: we only touch public APIs (field, column, entry, config), the DB stores plain strings, and we cap icon sets to what we actually use so page weight stays in budget.
• Ask: one spike ticket, one admin surface, acceptance criteria = styled modal, search works, selection renders in table and infolist, no measurable regression in admin asset size beyond the approved icon set(s).