Nova Icon Field Laravel Package

Product Decisions This Supports

• Build vs. buy for admin UX: This is a ready-made icon-picker control for Laravel Nova admin panels. The make-vs-buy call is trivial: the field is a thin wrapper over a configurable icon JSON set, so adopting it costs an afternoon versus days of custom Nova field work. The real decision it informs is whether admin-side icon selection is worth any dedicated UX at all — if editors are currently typing fa-solid fa-user into a free-text field and getting it wrong, a searchable picker is a cheap quality win.
• Content model for visual attributes: It forces an early, useful decision — store the neutral icon identifier (account-group) rather than a library-specific CSS class, and resolve it to a class or inline SVG per surface via a small app-side map. That keeps the public site decoupled from whatever icon font the CMS happens to ship, so switching icon libraries later is a config change rather than a data migration. This is the single most valuable product decision the package nudges you toward.
• Roadmap scoping for "icon" features: The field is deliberately narrow — single-select, no uploads, no multi-icon, no remote catalogues. It supports scoping a roadmap item like "let admins pick service/status/brand icons" to a two-day slice, and explicitly deselecting richer variants (custom SVG upload, user-generated asset libraries) that would require a different layer.
• Feature-level UX investment: Searchable lookup, preview in index/detail views, and per-field icon-set scoping map to concrete editorial pain — "I can't find the right icon" and "the wrong icon rendered on the marketing site." It supports prioritising a small internal-tooling improvement over a customer-facing feature when admin data quality is the bottleneck.
• Localisation and design-system alignment: Per-field icon set scoping lets different attributes (brand logos vs. status badges) draw from different catalogues, which supports a decision to standardise iconography per design-system surface without a global migration.
• Validation and data-integrity posture: Because the field validates only in the browser and will happily save any string, it surfaces a decision about whether the icon column is authoritative — requiring server-side Rule::in(...) or a custom membership rule wherever the attribute is exposed via API or import.

When to Consider This Package

Adopt it when all of the following hold:

• You are already on Laravel Nova 4 and have no plans to move to Nova 5 in the near term. Verify the README compatibility matrix before committing — a 2023 patch release does not guarantee it tracks a newer Nova major.
• The icon you need to store is a single, named icon from a curated set, and a plain string(255) column is the right shape.
• You can bound the icon set to something small — a trimmed JSON subset rather than the full Material Design Icons catalogue, which ships thousands of entries to the browser and visibly slows Nova form first paint on slow admin connections.
• You are comfortable that the field renders the selector only; table, export, PDF, and email rendering is your job, as is any backfill of existing free-text values.
• You accept the maintenance profile: 2 GitHub stars, last release April 2023, release notes that are a changelog link only. Pin ^1.0, never dev-main, and read the compare diff rather than trusting release notes.

Look elsewhere when:

• Nova 5 is on your roadmap within the next two quarters — you will likely be forking or replacing this.
• You need multi-select icons, custom SVG upload, or an SVG editor. Extension points are deliberately limited; bending Icon into these shapes ends in a fork. Wrap it in a custom field or store JSON in your own field instead.
• The icon catalogue is user-generated or remote (a brand asset library, an API-backed icon service). Keeping a JSON file in sync by hand will be more friction than a thin custom field over your own API.
• Supply-chain or long-term support risk is a hard constraint for your org — a two-star, single-maintainer package is fine for internal tooling but will fail a formal dependency review.
• You are not on Nova. This is a Nova field, not a standalone UI kit; there is no value here for Inertia/Livewire admin panels.

How to Pitch It (Stakeholders)

To executives (one paragraph): A small, free, MIT-licensed add-on for our Laravel admin panel that replaces error-prone free-text icon entry with a searchable picker. It costs roughly half a day to integrate versus several days to build in-house, and it pushes us toward storing neutral icon names rather than vendor-specific CSS classes — so a future redesign of the public site's icon set becomes a configuration change, not a database migration. Risk is low and contained: it is internal admin tooling only, it does not touch customer-facing code, and it stores a plain string column we could read with anything. The trade-off is maintenance maturity — two stars, one maintainer, last release 2023 — so we pin the version, add our own server-side validation, and treat any Nova major upgrade as a re-evaluation checkpoint.

To engineering (the ask): Add the field and column, publish and commit the config, scope each field's icon sets explicitly, trim the JSON to the subset the design system actually uses, add an in-style validation rule so the column is authoritative against non-Nova writes, and add a small identifier-to-class mapping so rendering stays decoupled from the icon library. Confirm the Nova 4 compatibility line and pin ^1.0. Document the failure mode everyone hits first: an empty grid almost always means a setIconSets() key that does not match the published config, because vendor:publish never overwrites an existing config and new keys silently fail to appear after upgrades.