Blade Elusive Icons Laravel Package

Product Decisions This Supports

• Build vs. buy for icon delivery. Adopt codeat3/blade-elusive-icons rather than building an internal SVG/Blade icon abstraction. It is a thin, auto-discovered wrapper over blade-ui-kit/blade-icons plus a pinned copy of the Elusive glyph set — a delivery mechanism, not a design system. "Buy" costs one Composer line and no build step; "build" costs a sprint and ongoing upkeep for the same outcome.
• Icons as a consistency and velocity lever. Standardizing on <x-elusive-* /> components replaces hand-pasted <svg> blobs and per-feature icon CSS with one pattern. Icons inherit currentColor, so Tailwind text-* utilities become the single colour convention, and default sizing lives in one wrapper component instead of scattered markup.
• Roadmap and framework-upgrade planning. Release 1.6.0 is compatibility-only: it widens the illuminate/support constraint to include ^13.0, with no new features, deprecations, or signature changes. That removes a potential hard blocker from the Laravel 13 roadmap item. PM-level caveat: a permissive constraint is not proof of tested compatibility — confirm CI actually exercises Laravel 13 before calling the upgrade de-risked, and check no other pinned dependency caps illuminate/support below ^13.0.
• Scope selection for feature work. Best fit is Blade-heavy, server-rendered UI: admin dashboards, internal tools, CRUD and settings screens, navigation, empty states, status indicators, and inline button/link affordances (download, delete, search). Poor fit: brand or product iconography, logo surfaces, or anything where a missing glyph is a launch blocker.
• Accessibility policy ownership. The package does not decide decorative vs. semantic icons. Passing title yields an accessible <title> node; otherwise icons should be treated as decorative. That is a product/a11y decision we make in templates and should be written down, not left to individual developers.
• Reversibility as a portfolio argument. No queue, cache, DB, or HTTP surface; icons render from vendor/. Swapping to a sprite sheet, Iconify, or an in-house pipeline later is a contained change if call sites go through one <x-icon> wrapper — so mandating that wrapper is itself a product decision worth making on day one.
• Risk register inputs. Single maintainer; 0 stars and 0 dependents means no observable production usage or community validation; upstream Elusive Icons is effectively frozen, so absent glyphs are a permanent "no," not backlog items. MIT license and zero telemetry keep legal and procurement cost near zero.
• Decision summary: adopt, scoped to internal/admin Blade UI; do not standardize org-wide; revisit if icon requirements grow beyond the frozen set or if icons become accessibility- or contract-critical.

When to Consider This Package

Consider it when:

• The product is a Laravel application rendered with Blade, and the team wants declarative component syntax without touching the asset pipeline or front-end build.
• Icon needs are conventional and internal-facing — navigation, actions, status — and the Elusive filled-glyph style is acceptable to design.
• The team is currently maintaining custom SVG partials or icon-font CSS and wants to delete that code.
• Laravel 13 is on the roadmap or in flight. 1.6.0 exists specifically to unblock that upgrade; teams on Laravel 11/12 should let it ride along with a routine dependency refresh rather than treating it as urgent.
• You want a cheap, reversible trial: one screen or one feature area, low blast radius, easy rollback.
• You already depend on blade-ui-kit/blade-icons or sibling codeat3/blade-*icons packages — the registration pattern is consistent, which lowers integration cost.

Look elsewhere when:

• The icon set is a growth requirement. Elusive Icons is frozen upstream; if the roadmap expects new or brand glyphs, this package cannot deliver them and never will.
• The design system mandates a specific library (Heroicons, Lucide, Font Awesome) or needs Iconify-style on-demand delivery and JS tree-shaking.
• Rendering happens outside Laravel, or server/client icon parity is required.
• A page renders hundreds of icons in loops — inline SVG per component inflates HTML payload and defeats caching of a shared sprite; standardize on a sprite or cached-icon approach first.
• Icon availability is an accessibility, contractual, or compliance requirement. Single maintainer, no SLA, and near-zero adoption signals make it unacceptable for a critical primitive.
• You would install multiple codeat3 icon packages without validating prefixes — duplicate prefixes silently shadow each other and ship the wrong glyph.

Adoption gate before standardizing: pin the exact version in composer.json and let the lock file record the resolution; add a Blade render assertion for every icon name used, because a misspelled icon renders nothing rather than erroring; audit resources/svg/ for coverage and license; verify the package's CI matrix actually exercises Laravel 13 and note the PHP floor it implies; and confirm no other pinned dependency blocks illuminate/support ^13.0 — that is the most likely reason the upgrade stalls instead.

How to Pitch It (Stakeholders)

For executives. This is a small, MIT-licensed Laravel package that gives us a fast, consistent way to put icons into Blade-based screens — one Composer install, used directly in templates, with no infrastructure, no build step, and no vendor contract. It is on the table now for one narrow, concrete reason: release 1.6.0 adds Laravel 13 compatibility, which removes a potential blocker from our framework-upgrade plan at effectively zero engineering cost. Two honest caveats: the underlying Elusive icon set is frozen and will never gain new glyphs, and the package is maintained by a single author with no adoption track record. That makes it a sensible cosmetic utility for internal and admin interfaces and a poor choice for anything customer-branded or contractually guaranteed. Recommendation: adopt scoped to internal/admin Blade UI, do not standardize org-wide, and revisit if icon requirements outgrow the frozen set.

For engineering. Treat it as a presentation-layer convenience only. The service provider is auto-discovered and registers the set with blade-ui-kit/blade-icons; config publishing is optional and not required by 1.6.0. The 1.5.0 → 1.6.0 upgrade is a Composer constraint bump with no application code change — land it atomically with the Laravel 13 framework upgrade rather than separately, so we never carry a partially validated matrix. Four things to get right up front: (1) wrap calls behind a single project-local <x-icon name="..." /> component so the icon library is swappable without a global find-and-replace; (2) add render tests, because an unknown icon name fails silently and would ship a blank glyph; (3) add php artisan icons:cache to the deploy script after composer install --no-dev, and icons:clear locally when bumping; (4) if we install any sibling codeat3 icon package, confirm prefixes don't collide. Report the Laravel 13 bump as "allows" not "verified" until CI coverage is confirmed, and treat the package as non-critical during future framework upgrades so it never becomes a false blocker in an upgrade retro.