Statamic Heroicons Laravel Package

Product Decisions This Supports

• Icon system standardization: This package wraps Heroicons for Statamic, letting content editors and templating use a curated, consistent icon set without hand-managing SVG files. Relevant to design-system and UI consistency initiatives.
• Build vs. buy/stewardship: A very thin integration layer — low build cost, but adds a third-party dependency to your templating surface. The v1.1.0 bump to Heroicons v2 means the underlying icon vocabulary (and naming) shifts with the upstream library, which is a content/design decision as much as an engineering one.
• Roadmap impact assessment: Any planned icon refresh, brand/design system update, or new marketing page templates should account for the Heroicons v2 migration — icon names, available weights/styles, and rendered markup may differ from v1.
• Use cases: Marketing/landing pages, navigation and UI affordances in Statamic-driven sites, editorial control of icons via the CMS, and rapid prototyping where a vetted open-source icon set is preferable to bespoke assets.

When to Consider This Package

Consider adopting when:

• You are running Statamic and want a low-configuration way to expose Heroicons to templates and/or the control panel.
• Your team is comfortable with Heroicons as the canonical icon set and accepts its MIT licensing and upstream release cadence.
• You want to avoid maintaining your own SVG sprite/partials pipeline for a modest icon requirement.

Look elsewhere when:

• You need icons beyond Heroicons (brand marks, custom illustration sets, multi-library support) — a more general icon fieldset or asset pipeline is a better fit.
• You require guaranteed API/asset stability across major upstream versions; this package tracks Heroicons releases and inherits their breaking changes.
• You are not on Statamic, or you need server-side-only rendering without CMS integration — a plain SVG component approach may be simpler.
• Accessibility tooling (semantic labels, ARIA presets) is a hard requirement out of the box; verify what the package provides versus what your templates must supply.

Adoption criteria / due diligence for v1.1.0 specifically:

• Inventory existing icon references in templates and content and diff them against the Heroicons v2 rename map before upgrading — treat this as a potential breaking change despite the minor version number, since the underlying icon names and available variants changed upstream.
• Check rendered markup/attributes for changes that could affect CSS sizing, stroke widths, or accessibility attributes.
• Confirm how the package pins or vendors the Heroicons set (composer dependency vs. bundled SVGs) to judge future upgrade risk.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost integration that gives our Statamic sites a consistent, professionally designed icon set managed through the CMS rather than ad-hoc image files. The new v1.1.0 release updates the underlying icon library (Heroicons v2), which is a refresh — the icons look cleaner and the set is reorganized, but some icon names changed. That means a short, scoped audit and template cleanup rather than a drop-in upgrade. Effort is measured in hours, not weeks, and there is no licensing cost (MIT). Recommendation: approve the minor upgrade with a scheduled content/template sweep, and treat icon naming as something we own going forward.

For engineering: Thin wrapper over Heroicons for Statamic. v1.1.0 is a single dependency bump to Heroicons v2 (PR #3, first-time contributor). Risk is concentrated in the upstream rename/reorganization of icons, not in package logic — so the work is grep-and-replace across templates and any icon references stored in content, plus a visual regression pass on key pages. No new APIs, no deprecations in the package itself. Low operational risk; pin the version if we need stability, and add an icon-name check to CI or a smoke test to catch future upstream drift.