Nova Hero Icon Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-panel icon UX. The package is a convenience layer, not a capability moat, so the real comparison is ownership burden versus build time — and build time here is measured in hours (roughly half a day to scaffold a Nova tool against current Heroicons). "Buy" costs almost nothing in license or install (MIT, one composer require), but it transfers maintenance to us on day one. This decision belongs in a build-vs-buy log with that framing, not a price comparison.
• Dependency-risk posture for non-core UI. Signals are unambiguous: 7 stars, 0 dependents, last release May 2020, no maintainer surface, no support channel. This is a clean test case for a standing policy of "vendor or fork anything we adopt; never depend on upstream for cosmetic admin affordances." The PM-useful outcome of rejecting it on maintenance risk alone is legitimate — it keeps a dead dependency out of the codebase before it becomes permanent tax.
• Sequencing against the Nova upgrade roadmap. The package is a rider on the Nova version decision, not a driver of it. Nova 4+ moved to Vue 3 and changed the tool/asset contract, so adoption is only coherent while we remain on Nova 2/3. That means icon work must be scheduled behind upgrade planning, never ahead of it, and any adoption should be logged as an item on the Nova-upgrade checklist.
• Design-system standardization. Useful for a decision to declare Heroicons the canonical icon vocabulary inside Nova and expose it consistently across resources, cards, metrics, and custom tools. Important caveat for that decision: the bundled SVGs are frozen at a 2020 revision, so standardizing on this package means standardizing on an old icon set whose names have since drifted (e.g. user-circle, annotation, dots-circle-horizontal). Standardize on the icon set, not on this package's snapshot of it.
• CMS / back-office use-case fit. Relevant only where non-technical editors need to tag categories, menu items, statuses, or content blocks with an icon without developer involvement. Confirm that need exists before scoping anything; if editors never touch icons, the decision closes immediately at zero cost.
• Do-nothing / defer as the default. For a non-core UI affordance, declining costs nothing today and preserves optionality. If the need is genuinely one screen, a half-day in-house component delivers the same result with a named owner and no fork obligation.
• Risk containment scope, if adopted anyway. The package's whole job is persisting an icon-name string; rendering is ours. Keeping the display layer independent (our own <x-heroicon> Blade component reading from a committed name list) means a Nova upgrade breaks only the picker, not the screens — a one-file replacement rather than a hunt.

When to Consider This Package

Consider it when:

• You are on a legacy Nova 2.x/3.x install (Laravel 6/7, PHP 7.x, Vue 2). This is effectively the only compatible configuration; a five-minute check of composer.json constraints is the go/no-go, and anything requiring Nova 4/5 should stop the evaluation there.
• You already use Heroicons as your icon vocabulary and want editors choosing from that set rather than pasting SVG paths.
• The requirement is internal-only and non-critical — an affordance where an unmaintained component failing is an annoyance, not a workflow outage.
• You can vendor or fork the source into your own VCS, pin the commit, and name an engineer who owns it. Without that commitment the package is disqualified outright; installing it makes us the maintainers.
• The requirement is narrow: pick an icon name, store the string, render it back. Search, categories, custom SVG upload, icon-set portability, and modern Heroicons revisions are out of scope.
• You are treating it as a reference implementation — reading its Vue component and rebuilding it inside your own nova:tool scaffold against a current Heroicons release. Given the tiny surface area, this is usually cheaper across a two-year horizon than carrying a fork.

Look elsewhere when:

• You are on Nova 4 or 5. A 2020-era tool will not render reliably against Vue 3, and there is no evidence of anyone running it on a modern stack. A blank or erroring panel is the expected result until a spike proves otherwise.
• You need security patching, vendor support, or maintenance guarantees. There is no issue history, no community answers, and no response path.
• Icon selection is load-bearing for an editor workflow. Build the minimal custom Nova field — comparable scope, maintainable result, real owner.
• You cannot accept fork ownership, or you run multiple Nova-versioned applications where you would inherit duplicate forks across majors.
• A maintained alternative exists — a current Heroicons Blade/Vue component with an active owner satisfies the same need without abandonment exposure.
• Failure would be silent and expensive. Invalid icon names render an empty SVG with no exception, no warning, and no log entry; if bad data reaching the database is unacceptable, hand-rolled validation and a visible fallback beat debugging this after the fact.

How to Pitch It (Stakeholders)

For executives: This is a tiny MIT-licensed add-on that lets editors pick Heroicons inside the Laravel Nova admin panel. Its strategic value is low and its maintenance risk is concrete: no release since May 2020, seven stars, zero dependent packages, and no maintainer response path. Recommendation: not a roadmap item. Treat it as an optional convenience for legacy admin screens only, and only if we vendor or fork the code so we are not exposed to abandonment — the moment it is installed, we become the maintainers, and that recurring cost (roughly a half-day at every Nova and Laravel major upgrade) exceeds the half-day it takes to build the equivalent ourselves. It moves no customer-facing metric, so it should never be sequenced ahead of the Nova upgrade work it depends on.

For engineering: Small surface area, awkward ownership. Its whole responsibility is storing an icon name and rendering a picker; the display layer should be ours from day one so a Nova upgrade breaks one file instead of many. Verify the real contract first (composer.json constraints, whether the class extends Field or Tool, which fluent methods actually exist) — the docs and the code disagree, and the assets may need a 2020-era Node toolchain to rebuild. Icon names come from a frozen 2020 Heroicons revision, so commit the bundled name list and use it as both the picker source and a Rule::in() validator; silent empty renders are the default failure mode otherwise. Scope it to one or two resources, pin the version, and add the fork to the Nova-upgrade checklist. If we're on Nova 4+, the honest path is to reimplement the Vue side against current Heroicons — about half a day, no fork obligation, no stale build.

For the requesting team: We can deliver the same editor experience — pick a Heroicon, save it, render it on the detail screen — without taking on an unmaintained dependency. Expect roughly half a day of engineering either way; the difference is that one option leaves us with a component we own and can extend, and the other leaves us with a pinned fork and a standing upgrade tax.