Blade Evil Icons Laravel Package

Product Decisions This Supports

• Build vs. buy: adopt, don't build. An icon-delivery layer carries zero product differentiation. codeat3/blade-evil-icons wraps the Evil Icons SVG set as ready-made Blade components (<x-evil-o name="search" class="w-4 h-4" />), so the team stops hand-managing SVG files, sprite sheets, or an icon-font pipeline. Writing equivalent components in-house is pure overhead with no product upside.

• Feature velocity on Blade surfaces. The package removes a recurring tax from UI work on admin panels, internal tools, and MVPs: an engineer drops a Blade tag into a layout, styles it with existing Tailwind/CSS utilities, and moves on. The PM lever is fewer front-end assets to source, review, and maintain — no npm dependency, no Vite step, no design-asset handoff for routine icon needs.

• Roadmap signal: low but non-zero. Release 1.7.0 is a single change — Laravel 13 compatibility (PR #10). Read it as sustained-maintenance evidence, not feature investment. It is a reason to keep the dependency current, not a reason to schedule roadmap work or a migration project against it.

• Framework-upgrade planning input. The Laravel 13 bump removes this package as a blocker on any surface that depends on it. If a Laravel major upgrade sits in the next 1–2 cycles, this is a green light for the icon layer — subject to verifying the constraint range, which is the single most likely source of a failed composer update.

• Design-system decision, made once. Icon-set choice is a brand/design decision, not a product capability, and should be settled in a decision record so it does not resurface as a per-feature debate. The trade-off to accept explicitly: Evil Icons is a small, effectively frozen style, so committing to it means committing to narrow coverage.

• Commodity, not differentiator. Budget for it as replaceable infrastructure: pinned, kept current, cheap to swap. Do not build brand-critical or accessibility-sensitive, customer-facing UI that depends on this package's specific behaviour.

When to Consider This Package

Consider adopting when:

• The stack is Laravel with server-rendered Blade (or Livewire). Fit is high for a monolith, or an Inertia/Vue app that renders Blade layouts; it is not applicable to API-only or non-Blade front ends.
• The product genuinely wants the Evil Icons set specifically — thin-line, distinctive, limited coverage — and design has signed off on that choice.
• You need a small number of icons in low-complexity views with zero build-step involvement: no npm, no Vite, no SVG import plumbing.
• You value minimal dependency surface over breadth of coverage, and are comfortable pinning a single-maintainer package.
• You are refreshing dependencies anyway. This slots into an existing maintenance window rather than justifying a dedicated change request.

Look elsewhere when:

• Icon needs will grow or span multiple families. Use a multi-set solution from the blade-icons ecosystem (this package is itself a thin blade-ui-kit/blade-icons wrapper). Committing to one narrow set creates template-wide rework later.
• Coverage is a real requirement. Evil Icons is a legacy, essentially frozen family. If the backlog implies a broad or evolving icon vocabulary, the set becomes the constraint.
• Accessibility is a hard requirement. Confirm the component permits aria-hidden, role, <title>, and focusable handling before putting it in customer-facing flows.
• You need optimization guarantees — tree-shaking, per-icon splitting, minification. Blade renders what you include; there is no bundler-level pruning, and inline SVG inflates HTML on icon-dense pages.
• Supply-chain risk tolerance is low. One maintainer under the CodeAt3 org, zero stars, zero dependents. Treat as commodity infrastructure, never critical path.
• The front end is JS-first (React/Vue SPA, Next.js). Consume the icons on the npm side instead.

Adoption guardrails:

• Pin to ^1.7 and commit composer.lock so CI and prod resolve identically.
• Verify the actual composer.json constraints: does 1.7.0 widen the Laravel range or pin to 13 only? Confirm the PHP minimum matches runtime and lock files per environment, and check the blade-icons constraint and whether SVG is inlined or delegated (CSP/sanitisation implications).
• Confirm license/attribution terms for redistributing the icon set (MIT for the wrapper; verify the artwork).
• Keep a vendored copy of the SVG set so icons survive package abandonment.
• Pilot in one or two high-traffic layouts, check rendered output against the visual baseline and CSP, then sweep template-by-template — keeping legacy assets until a full grep confirms zero references.
• Do not bundle this into the same deploy as a Laravel major upgrade; keep framework and view-layer changes separately rollback-able.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a small, free, MIT-licensed add-on that lets our Laravel engineers drop icons into the interface without any custom asset work — a modest, low-risk time saver on internal tools and MVPs. Release 1.7.0 does exactly one thing: adds compatibility with the next Laravel version, which keeps our upgrade path clear. No license cost, no vendor commitment, no infrastructure. The trade-offs are honest and bounded: one narrow icon style, a single maintainer, and no optimization tooling. So we treat it as a replaceable commodity — pinned, kept current, kept out of brand-critical UI, and swappable cheaply if it ever stalls.

For engineering: 1.7.0 is a compatibility-only release — Laravel 13 support, no API changes, no deprecations, no new features. That is the good outcome: the package is still maintained and will not block a framework upgrade. Recommendation: pin ^1.7, keep it current, and verify the Laravel 13 claim against the version we actually run — specifically whether the constraint is a range (e.g. 10–13) or a 13-only pin, since that determines whether composer update breaks on older environments. Adoption is low effort: auto-discovered service provider, evil-o component prefix, name maps to a filename in the package's resources/svg/. Known limits to be explicit about: single narrow icon set, single maintainer, no tree-shaking or per-icon splitting, and inline SVG that interacts with CSP and global fill/stroke CSS, plus accessibility attributes that need validating. Treat it as an additive first pass — replace ad-hoc <img> and FA <i> tags layout by layout, verify rendering, and decommission legacy assets only after a clean grep. If icon requirements broaden beyond this set, plan a migration to a multi-set blade-icons solution rather than extending this one; swapping later means touching every template, so flag that now rather than after the sweep.