Fontawesome Picker Bundle Laravel Package

Product Decisions This Supports

• Admin/CMS personalization surface. A Font Awesome picker is the kind of widget that gates features like custom menu icons, category/tag badges, status indicators, or theme-level iconography. If "let admins brand their workspace with icons" is anywhere on the roadmap, this is the cheapest possible probe of that feature's value.
• Build vs. buy for a ~200–400 LOC UI widget. The package's scope is narrow: render a searchable grid of icon classes and return the selected class name to a form field. That scope is small enough that the build/buy decision should be made on maintenance and compatibility, not engineering cost — which argues against adoption of an unmaintained artifact.
• Font Awesome version strategy. Any icon-picker decision is downstream of a bigger platform call: FA4 (font + CSS classes) vs. FA5/6 (SVG, icon-name renaming, fa-solid/fa-regular styles, Pro-only packs). A picker locked to 2017-era class names constrains that call rather than supporting it.
• Symfony-vs-Laravel platform fit. Despite the framing, this is a Symfony 2+ bundle (redking/fontawesome-picker-bundle), not a Laravel package. Bundles register through Symfony's kernel and service container; there is no ServiceProvider/Facade equivalent. For a Laravel product this decision is effectively rejected on integration grounds before evaluation begins — useful as a written "no" in the ADR log.
• Vendor-risk register entry. 2 stars, 0 dependents, last release November 2017, and a composite score of 0.14 make this a textbook abandoned dependency. Documenting the rejection is itself a product decision: it prevents the same evaluation from being redone next quarter.

When to Consider This Package

Consider only under a narrow, unusual set of conditions:

• The codebase is a live Symfony 2.x/3.x application that is already pinned to Font Awesome 4.x, and the team has an explicit no-new-UI-work policy on that legacy stack.
• The picker is needed for an internal, low-risk admin screen — not a customer-facing surface with accessibility or i18n requirements — and the alternative is a hand-rolled <select> with hardcoded icon names.
• A time-boxed spike (a few hours) to demonstrate an icon-selection UX to stakeholders before committing to a build. Treat it as a disposable prototype, not a dependency.
• You can vendor-pin it, audit the ~handful of PHP/Twig/JS files yourself, and accept that you are now the maintainer.

Look elsewhere when:

• The target stack is Laravel or any non-Symfony PHP framework. There is no meaningful port story; the picker logic is entangled with Symfony form types and Twig templates.
• You need Font Awesome 5/6, SVG icon rendering, or icon-style variants. Class naming and rendering changed materially after FA4; a 2017 picker will not model fa-solid/fa-regular/fa-brands or Pro kit semantics.
• Accessibility, keyboard navigation, search quality, or localisation are requirements. There is no evidence of active a11y work, and zero dependents means zero ecosystem pressure to keep it current.
• Security or supply-chain review is mandatory. An eight-year-dormant package with no release since 2017 and no visible maintainer activity is a poor vendor posture, even for a UI-only widget with a small surface.
• You need a supported dependency. "Who fixes this when FA7 ships?" has no good answer here.

Practical alternatives to weigh in the same decision: Font Awesome's own maintained JavaScript picker, a generic searchable-icon-picker library driven by a JSON manifest of icon names, or a short in-house build (icon-name list + fuzzy search + a form field). None carry the abandonment risk.

How to Pitch It (Stakeholders)

To executives: This is a small UI convenience — a widget that lets an admin pick an icon from the Font Awesome set — packaged as a Symfony bundle. It has 2 GitHub stars, no downstream dependents, and no release since November 2017. The underlying idea (icon personalization in admin tooling) is worth a roadmap conversation; this specific artifact is not worth adopting. Cost of adopting is not licence fee (it's MIT, free) but ownership: we would inherit an unmaintained component on a platform that isn't ours. Recommendation is do not adopt; the capability, if we want it, is a 1–2 day build or a swap to a maintained picker.

To engineering: It's a Symfony 2+ bundle tied to Font Awesome 4-era class names — not usable in our Laravel application without a rewrite, at which point we've done the build anyway. Scope is narrow: an icon manifest, a searchable grid, and a form field returning the selected class. If icon selection lands in an upcoming sprint, estimate it as a small ticket against a maintained icon set (FA6 or an equivalent) with a JSON-driven manifest, so the picker survives future Font Awesome releases without code changes. Flag the rejected dependency in the ADR log so this isn't re-litigated.

Decision in one line: Reject as a dependency; keep the feature concept on the backlog and size the build against a current icon set.