derteaser/statamic-blade-icons
Statamic addon that integrates Blade Icons, letting you render cached SVG icons in Antlers templates, Bard fields, and control-panel views through a simple tag, with support for multiple icon sets and custom CSS classes.
Architecture fit. derteaser/statamic-blade-icons is a thin bridge package, not a standalone Laravel library. It wires blade-ui-kit/blade-icons (an SVG icon registry and <x-icon> Blade component set) into Statamic's Antlers/Blade rendering pipeline, giving content authors a tagged icon syntax alongside Statamic's own template layer. Architecturally this is a low-coupling addon: it depends on Statamic's addon service-provider contract and on the host app's Blade compiler, and it owns no persistence, no routing, and no queue surface. That makes it cheap to evaluate and cheap to remove, but it also means it inherits the version constraints of two upstreams at once (Statamic major, blade-icons major/Laravel major).
Integration feasibility. High for teams already on Statamic 4/5 with Blade as the rendering engine. The integration is essentially: composer require, register the provider via Statamic's addon discovery, configure one or more icon sets in config/statamic/blade-icons.php (or equivalent), then use the resulting tag/component in templates. The realistic friction points are (a) icon-set sourcing — most teams will pull from a package like blade-ui-kit/blade-heroicons or a local SVG directory, which needs a build/cache step documented, and (b) coexistence with any pre-existing icon solution (Statamic's native asset-based SVG approach, or an in-house partial). Neither is a blocker, but both are adoption sequencing questions rather than pure install questions.
Technical risk. Moderate-low, with one material item in this release. v0.8.0 removes the custom icon picker. That is a control-panel UX regression for any editor workflow that depended on browsing icons visually inside the CMS — those users fall back to knowing the icon name or consulting documentation. Because the package is pre-1.0 (0.x), this is semver-permissible and should not be read as a stability signal either way, but it does mean the CP experience is now unmanaged and teams should not promise editors a picker. Secondary risks: the dependency upgrade pass is unspecified in the notes, so the effective constraint change on blade-icons/illuminate/*/Statamic is unknown without diffing composer.json; and the addon's bus factor is a single maintainer with a low release cadence (0.7.0 → 0.8.0), so long-term maintenance is a genuine consideration rather than a formality.
Key questions.
Stack fit. Clean fit for Statamic 4/5 on Laravel 10/11 with Blade rendering. Poor fit — effectively a non-starter — for Antlers-only sites that have deliberately avoided Blade, and for any project where icons are already solved by an existing asset pipeline. Treat this as an optional developer-experience addon, not infrastructure.
Migration path. Because there is no prior assessment and no existing adoption, the migration path is a greenfield pilot rather than a migration. Recommended path: install v0.8.0 directly (do not attempt 0.7.0 → 0.8.0 as a stepping stone; there is no reason to onboard onto the version whose picker is about to be deleted), stand up a single icon set against a non-critical template, and validate rendering in both the CP preview and the static-cached front end before broadening usage. For any project already on 0.7.0 with the picker in active editorial use, the upgrade is a deliberate UX trade — schedule it, announce it, and rewrite the affected blueprint instructions in the same release window.
Compatibility. The two hard gates are Statamic major and Laravel/blade-icons major. The release notes' "upgrade dependencies" line is the only signal we have, and it is insufficient for a compatibility decision — read the composer.json diff at the v0.8.0 tag before approving. Also confirm the PHP floor; pre-1.0 addons in this ecosystem frequently move it. Third gate: any project using Statamic's static caching should verify icon SVGs are inlined or emitted as cacheable assets rather than resolved per-request.
Sequencing. (1) Pin and verify constraints from the tagged composer.json. (2) Pilot in a single non-production environment with one icon set. (3) Confirm no blueprint/fieldset still references the removed picker. (4) Update author documentation with icon-name lookup guidance to replace the lost picker. (5) Roll to production behind the existing static-cache warmup. (6) Re-evaluate at 1.0 or at the next minor, whichever comes first — for a 0.x single-maintainer addon, the assessment should carry a review trigger rather than be treated as settled.
Maintenance. Low steady-state cost. The package is small, has no runtime state, and its only recurring burden is tracking two upstream majors. The real maintenance exposure is governance: one maintainer, three-commit releases, and a changelog that describes category of change ("Maintenance", "Upgrade dependencies") rather than content. Budget for reading diffs yourself each release; do not plan to rely on release notes for impact analysis.
Support. No commercial support, no LTS branch, no security policy evident. Acceptable for a rendering-layer convenience addon with no data custody and no auth surface — the blast radius of abandonment is "icons stop rendering after a Statamic major," not "site goes down." It should not be allowed to become load-bearing for anything beyond template presentation.
Scaling. Effectively free. Icon resolution is compile/cache-time and per-template, not per-record; there is no query, no N+1, and no write path. The only scaling-adjacent concern is build-time: large icon sets inflate the compiled asset/cache footprint, so keep registered sets scoped to what templates actually use rather than registering entire icon libraries wholesale.
Failure modes. (1) Silent render failure — a renamed or unregistered icon yields an empty or fallback SVG rather than an exception, so breakage appears in production markup, not in CI; mitigate with a template-level smoke test asserting icon output on a known key page. (2) Post-upgrade blueprint breakage from the removed picker — the field may degrade quietly in the CP, which editors will notice before engineering does. (3) Constraint drift — a routine composer update in the host app resolving a blade-icons version the addon has not been tested against. (4) Static-cache staleness if icon sets change without a warmup. (5) Single-maintainer abandonment after a Statamic major release, which is the realistic end-of-life scenario and should be documented as such.
Ramp-up. Under a day for a Laravel-fluent developer: composer install, one config file, one icon set, one template change. The editor-facing ramp-up is the part that changed in this release — with the custom picker gone, editors must learn icon names from documentation or a reference page rather than browsing. That is a small but real training cost, and it should be written into the release communication rather than discovered on publish day. Net recommendation: adopt for presentation-layer templating where Blade is already in play; do not adopt as a CMS editing feature, and re-assess at 1.0.
How can I help you explore Laravel packages today?