Icon Selector Bundle Laravel Package

Product Decisions This Supports

Stack-fit correction that shapes every downstream decision: despite the "Laravel/PHP package" framing, this is a Symfony bundle (nowo-tech/icon-selector-bundle) — a Symfony Form Type that depends on Symfony UX Icons sets. For a Laravel roadmap it is inspiration, not a dependency; for a Symfony roadmap it is directly adoptable. Decide which of those two conversations you are actually having before spending any PM time on it.

• Build vs. buy for a commodity admin UI. An icon picker is a small, non-differentiating widget: a grid of icons plus text-search filtering, writing a namespaced string (heroicons:outline:home, bi:house). Scope is genuinely tiny, which is exactly the profile where buying/adopting beats building. The counterweight is that "small" also means building it is cheap — so the buy case rests on speed and maintenance, not capability.
• Data model decision: string identifier vs. file vs. foreign key. The package's core product contribution is a convention — the stored value is a portable string, not an uploaded SVG, not a row ID. That supports content APIs, exports, fixtures, environment parity, and re-rendering icons at runtime without a media pipeline. If your CMS/admin stores icons as uploads today, this is a cheap argument for migrating to named identifiers.
• Back-office self-service roadmap. Any feature where a non-technical user chooses an icon — menu builder, category/taxonomy badges, page-builder blocks, notification types, email template slots, status labels — stops being an engineering ticket. That unblocks admin UX work that is otherwise perpetually deprioritized behind customer-facing features.
• Design-system governance. Exposure of icon libraries is configuration-driven, so "which icon sets are allowed in our product" becomes an explicit, reviewable decision instead of an accident of what a developer imported. Useful lever for brand consistency and for shrinking the catalog before the search UX degrades.
• Dependency-risk posture. 0 stars, 0 dependents, single-maintainer profile, and a low composite maturity score mean this is an experiment-tier dependency. That is a portfolio decision — adopt behind a wrapper, sandbox it to one admin surface, and treat "replace with 150 lines of our own form type" as a known, budgeted exit rather than a scare.
• Roadmap sequencing input. Because it is a Form Type, it composes with existing Symfony forms — no new pipeline, no new auth model, no migration. That makes it a low-ceremony "yes" for a spike and a poor candidate for a platform-wide standardization initiative in the same quarter.

When to Consider This Package

Adopt (pilot) when most of these hold:

• The application is Symfony 6/7/8 on PHP ≥ 8.1 and already (or is willing to) use Symfony UX Icons — the bundle config selects from UX Icons sets, so UX Icons is a real dependency, not an optional extra.
• At least one form field's value is genuinely an icon name, and the people filling that form are not developers.
• The candidate catalog is large enough that browsing a grid is insufficient and text search matters (the two-mode selector/search design is the actual value over a plain <select>).
• You want values to stay plain strings for API payloads, imports/exports, or seed data.
• Your team has no appetite to own a custom form type plus front-end assets, and one sprint of "commodity widget" work is not worth the calendar.
• Engineering accepts a wrapper/anti-corruption layer and version pinning around an unproven, zero-adoption dependency.

Look elsewhere (or build in-house) when any of these hold:

• The stack is Laravel. There is no portable Laravel integration here; you would be re-implementing the concept (form field + searchable grid + icon-set registry) anyway, so "buy" collapses into "build."
• You need icon uploads, arbitrary SVG acceptance, sanitization policy, or asset storage — this is a selector over an existing icon set, not a media manager.
• Your value is more than one token: icon plus color, ordering, multi-icon, or per-locale icon variants will not fit a single string field cleanly.
• Your design language relies on a proprietary icon font or in-house set not published as a UX Icons set.
• You require vendor support, an SLA, a security-review trail, or a maintained release cadence — none of that is present at this adoption level, and "last release 2026" is a provenance detail worth verifying rather than trusting.
• The field lives in a high-traffic, critical admin path where a silent break in a 0-star dependency becomes an incident. Build the 100–200 line form type and keep ownership.
• You have hard, documented accessibility and i18n requirements for the picker (keyboard grid navigation, screen-reader labeling, RTL). This is unverified here — treat it as a gap to test, not a feature to assume.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, MIT-licensed Symfony component that lets non-technical staff pick an icon from our design system inside admin forms, with search. It removes a recurring "can you add an icon field?" dev request from the backlog and keeps icon choices consistent instead of ad-hoc. Cost is one composer dependency and roughly a sprint of integration and review; the scope is small enough that replacing it with in-house code later is a contained task, not a re-platforming. Recommendation: pilot in one admin form this quarter — do not standardize on it yet.

To engineering leadership (the honest version):

• It is a thin Symfony Form Type over Symfony UX Icons; the value is the two-mode picker (grid + text filter) and the string-value convention.
• Adoption signals are effectively zero — no stars, no dependents, one apparent maintainer. Treat it as unvetted open source, not a vendor.
• Mitigations are cheap and non-negotiable: pin the version, wrap it in our own form type so the public surface is ours, add a form-level functional test, and confirm it renders and stores the values we expect before it reaches a user-facing admin screen.
• Exit cost is low by construction: it is one field type. Document that exit so the dependency argument never escalates.

To the business, the risk in one line: the downside is a broken admin form field we can replace in days; the upside is removing an entire class of small, recurring engineering requests. That asymmetry is why it is worth a bounded pilot — and why it is not worth a platform decision.

Explicit non-claim: this package does nothing for a Laravel codebase. If the roadmap in question is Laravel, the correct output of this assessment is a build estimate for an equivalent field, not a procurement.