Nova Font Awesome Field Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-side micro-features. This package answers a very narrow question — "can we give editors an icon picker in Nova without writing one?" — and the answer is effectively "buying costs more than building." At ~1 day of engineering to build a Nova Select field backed by a static Font Awesome manifest, this is a build decision, not a procurement decision.
• Iconography strategy. Any roadmap item that involves editors choosing icons (service cards, category badges, menu items, feature callouts) needs a decision on the icon library itself — Font Awesome Pro, Font Awesome Free, or an SVG sprite set like Heroicons. This package hardcodes a Font Awesome assumption and locks that choice in early; it should not be the thing that drives the decision.
• Feature scoping for CMS-driven marketing pages. Useful signal for whether "editable icon on a content block" is a real requirement or a nice-to-have. If it's real, the field is a half-day of work; if it's a one-off, an enum column plus a hardcoded map is cheaper and more maintainable.
• Technical debt tracking. This package is archived, last released April 2023, zero dependents, three stars. Any existing usage should be logged as a known liability on the roadmap rather than left invisible.
• Vendor/OSS intake policy. A good test case for whether the team has a bar for adopting dependencies. A 3-star archived package with no dependents would fail almost any reasonable intake checklist — useful precedent when formalizing that policy.

When to Consider This Package

Consider only in a narrow band:

• You are on Laravel Nova 3 (or a Nova version this was built against) and cannot upgrade.
• You are standardized on Font Awesome 5 Free and have no plans to move to FA6 or a Pro set.
• You want a reference implementation to fork, not a live dependency — the source is small and MIT-licensed, so lifting the Vue component and icon manifest into your own codebase is a legitimate path.
• The icon field is non-critical — admin UX convenience, not a data-integrity or customer-facing concern.

Look elsewhere — or build — when:

• Nova 4 or 5 is in play. No releases since April 2023 and an archived repo means no compatibility commitment. Nova's field APIs and asset pipeline have moved.
• Font Awesome 6 is the target. FA6 renamed and added icons; a stale manifest silently offers editors icons that no longer render.
• You need icon search, SVG inline rendering, or Pro/duotone support. This is a picker, not an icon management system.
• Security or long-term maintenance review is required. Archived, single-maintainer, zero downstream users means no one else is finding the bugs. Treat it as unmaintained code you would own outright.
• Alternatives fit better: maintained Nova icon fields (outl1ne/nova-icon, optimistdigital/nova-icon), or simply Nova's native Select/Text field with your own icon list — often the lowest-risk answer.

How to Pitch It (Stakeholders)

To executives: There is no decision here worth escalating. This is a three-star, archived Laravel Nova field that adds an icon picker to the admin panel. It has no users, no releases in over two years, and no maintainer commitment. We are not adopting it. If editors need to pick icons, engineering builds the equivalent in about a day using Nova's built-in field types — lower risk, no dependency, and it stays current with whichever icon library we standardize on.

To engineering: Do not add this as a dependency. The scope is genuinely small — a Vue select component plus a JSON icon manifest — and reproducing it gives us control over the Font Awesome version, which the package does not. If we already use it anywhere, flag it for replacement at the next touch. If we want a head start, fork the component under MIT and vendor it in; do not point composer.json at an archived upstream.