Heroicon Laravel Package

Product Decisions This Supports

• Nova upgrade planning (Nova 3 → Nova 4): This release is a hard dependency gate. If the roadmap includes a Nova 4 migration, the icon package must move from ^1.0 to ^2.0 as part of that workstream — it cannot be upgraded independently of the Nova major version. Conversely, teams staying on Nova 3 must pin ^1.0 and deliberately defer this release. Either way, it is a line item in the migration plan, not an incidental composer update.
• Dependency pinning and release policy: The maintainer shipped an unversioned-in-spirit breaking change tied to a vendor major. That argues for pinning exact/compatible constraints (^2.0 for Nova 4, ^1.0 for Nova 3) and freezing icon-package upgrades behind the platform upgrade ticket rather than allowing them to float.
• UI/theming consistency work: "Change styles for support light and dark theme" and fill='currentColor' on Font Awesome icons are visual behavior changes. This creates a QA/regression task for dark-mode and icon-tinting across admin screens — a design-system consistency decision, not just an infra one.
• Build vs. buy for iconography: This package is a thin wrapper over Heroicons/Font Awesome for Nova. It reduces the question to: adopt a small third-party wrapper, or ship your own Blade icon components. Relevant to any decision about standardizing an icon set across the admin panel.
• Upgrade sequencing / release readiness: Because the change is breaking and single-maintainer, it feeds a go/no-go criterion for the Nova 4 cutover: confirm the icon package version, confirm rendered icons in both themes, then proceed.

When to Consider This Package

Adopt when:

• You run Laravel Nova and want Heroicons and/or Font Awesome available in Nova resources, fields, and custom tools without hand-rolling SVG components.
• You are migrating to Nova 4 and want an icon solution that already tracks the vendor major (^2.0.0).
• Your admin UI supports or plans to support light and dark themes — this release explicitly targets that.
• Your icon needs are cosmetic and non-critical; the blast radius of breakage is low.

Look elsewhere / treat with caution when:

• You are on Nova 3 and not migrating soon. Stay on ^1.0; do not adopt ^2.0.0. Note that ^1.0 is now effectively in maintenance-only status for Nova 3 users.
• Single-maintainer risk is unacceptable. This is a small, one-maintainer package (AlexAzartsev) whose release cadence is driven by Nova's own majors. If iconography is design-system-critical, consider vendoring the SVGs or writing your own components — the underlying assets (Heroicons, Font Awesome) are freely available.
• You need icon semantics beyond display — accessible labels, sprite optimization, tree-shaking, dynamic icon registries. A thin Nova wrapper isn't the place to solve that.
• You have strict change-control / SBOM requirements where a breaking major published solely to chase a vendor major needs more support guarantees than this project offers.
• You need icons outside Nova (front-end app, emails, PDFs) — this package is Nova-scoped; a general Blade/Vite icon pipeline would serve better.

How to Pitch It (Stakeholders)

For executives: A small third-party icon add-on for our Laravel admin panel (Nova) has shipped a new major version whose only real purpose is to support Nova 4. There is no new capability of business value — it's a compatibility release. The decision it forces is scheduling: if and when we move the admin panel to Nova 4, this package must move with it in the same change; until then we stay pinned to the old version. Cost is low and the risk is contained, but it should be tracked as a dependency of the Nova upgrade decision rather than a standalone initiative.

For engineering: v2.0.0 adds Nova 4 support and is an explicit breaking change — Nova 3 users must remain on ^1.0; Nova 4 requires ^2.0. Upgrading is a composer constraint change, but plan for visual regression: default styles now support light and dark themes, several icons were fixed, and Font Awesome icons gained fill='currentColor' so they inherit text color. Pin the constraint, upgrade only in lockstep with the Nova major, and add a dark-mode icon QA pass to the migration checklist. Note the package is single-maintainer and small — keep a fallback path (vendored SVGs or internal Blade components) in mind if maintenance lapses.