Statamic Blade Icons Laravel Package

Product Decisions This Supports

• Icon system consolidation: Evaluate whether this package lets a Statamic-backed product use one icon source (Blade Icons / SVG sets) across both Antlers/Blade templates and the control panel, replacing ad-hoc icon partials or a separate icon-font pipeline.
• Build vs. buy for editorial tooling: The v0.8.0 removal of the custom icon picker is a concrete data point for the "buy" side of the ledger — a community addon at 0.x is not a stable platform for a first-class authoring experience. If icon selection by editors is a product requirement, budget for owning that UI rather than inheriting it.
• Roadmap sequencing: Any roadmap item that assumes "editors pick icons from a visual picker in the CMS" must be re-scoped against v0.8.0. Either pin to 0.7.x (accepting the maintenance burden of an unmaintained fork point) or plan the picker as in-house work.
• Upgrade cadence policy: This release is dependency bumps plus a feature removal — a useful forcing function to define whether the team tracks 0.x addons automatically or gates them behind manual review.
• Use cases that remain sound: Read-only/developer-curated icon usage (icons chosen in code, referenced by name in content) is unaffected by the picker removal and is the strongest fit for this package today.

When to Consider This Package

Consider it when:

• The stack is Statamic on Laravel, and the team already standardizes on blade-ui-kit/blade-icons (or wants to) as the single SVG icon source.
• Icons are selected by developers/designers in templates, or referenced by stored name — not chosen by non-technical editors through a control-panel UI.
• You want to avoid maintaining a bespoke icon-registration layer and are comfortable depending on a small, single-maintainer community addon.
• You can accept 0.x versioning: no SemVer stability guarantee, minor releases may remove features (as v0.8.0 demonstrates).

Look elsewhere — or plan to build in-house — when:

• Editor-facing icon picking is a hard requirement. The custom icon picker was removed in v0.8.0; the package no longer covers that job.
• You need vendor SLAs, security review sign-off, or a published deprecation policy. A single-maintainer 0.x addon with "maintenance" releases is a poor fit for regulated or long-lived products.
• Your icon needs are runtime/brand-critical (white-labeling, per-tenant icon sets) where a silent upstream change is a customer-visible regression.
• You are not on Statamic. This is a Statamic addon, not a general Laravel package — for plain Laravel, depend on blade-icons directly.

How to Pitch It (Stakeholders)

To executives: This is a small community addon that lets our Statamic CMS share one icon library with our front-end code, which reduces duplicate assets and design drift. The latest release (v0.8.0) is mostly housekeeping but removes a visual icon picker — an editor convenience we do not currently depend on. Recommendation: adopt it narrowly for developer-managed icons, and do not put editor-facing icon selection on the roadmap without separately funding that UI.

To engineering: v0.8.0 upgrades dependencies and drops the custom icon picker (PR #103) alongside maintenance work (#104). Treat this as a minor-but-possibly-breaking change despite the version number: audit any usage of the picker component or its control-panel registration before upgrading, and pin to 0.7.x if you rely on it. Expect continued churn — this is 0.x with a single maintainer, so wrap it behind our own thin abstraction (an icon-name fieldtype or a small resolver) so a future removal costs us a config change, not a refactor. Before committing, confirm our Statamic and blade-icons versions satisfy the upgraded dependency constraints, and check whether the removal in #103 has a documented replacement path; if not, assume none is coming.