Blade Eva Icons Laravel Package

Product Decisions This Supports

• Shipping polished server-rendered UI without a front-end build step. This package exposes the Eva Icons set (~490 glyphs, each in outline and fill) as Blade components, so a Laravel/Blade product can add navigation icons, button affordances, status indicators, empty states, and dashboard chrome without introducing an npm/Vite icon pipeline, a sprite-sheet build, or an icon-font dependency. For a PM, that is a schedule and toolchain decision as much as a technical one: it removes a workstream (icon asset management) from the critical path of shipping screens.
• Build vs. buy vs. design. Adopting means a curated, MIT-licensed, professionally drawn icon set at zero licensing cost and near-zero integration cost (composer require and a Blade tag). The alternative paths are commissioning custom iconography (design spend, ongoing ownership) or maintaining an in-house SVG library (permanent maintenance liability). The honest trade-off: Eva's visual language is generic and widely seen, so this is commodity infrastructure, not brand differentiation. Adopt it to buy speed, and expect no brand equity from it.
• Roadmap and framework-upgrade planning. v2.2.0 adds Laravel 13 support via a composer constraint change (PR #15). The decision-relevant signal for a PM is not the feature — there are none — but that this dependency will not appear on the upgrade risk register. It is one fewer "will this block our Laravel 13 migration?" conversation. Low priority, low attention, no migration work.
• Standardising an icon API across the codebase. Committing to one Blade-component convention for icons reduces front-end/back-end handoff friction and turns a future icon-set swap into mechanical template edits rather than a UI rewrite — provided the team wraps the package components in a single internal component rather than calling eva-icons-* directly across hundreds of views. That wrapper is the real architectural decision; the package choice is easily reversible, the convention is not.
• Use cases this fits well. Admin panels and back-office dashboards, internal tools, MVPs and prototypes, client portals, and any Laravel surface where icon fidelity is low-stakes and iteration speed is high-stakes. Also a reasonable default for teams with no designer on hand who still need icons to look intentional rather than improvised.
• Explicit non-decisions. Do not treat this as a long-term brand-asset strategy. Do not plan around new icons arriving — upstream Eva Icons is effectively frozen in maintenance mode. Do not adopt it as a design-system foundation; it is a convenience layer over a static set.

When to Consider This Package

Consider adopting when:

• The stack is Laravel + Blade with a server-rendered UI and no meaningful JS icon pipeline — this is the case it is built for.
• You want a consistent icon set live in an afternoon: composer install, no publish step, no asset compilation, no registration.
• MIT licensing is acceptable and you want no attribution overhead beyond retaining the license file.
• Your team is small and values keeping dependencies out of the JS toolchain.
• You are on or planning Laravel 13 — v2.2.0 explicitly supports it, so pin ^2.2.
• You are willing to invest the small upfront effort of an internal <x-ui.icon> wrapper to keep the package prefix out of your templates.

Look elsewhere when:

• You need brand-specific or custom iconography → design-system SVG pipeline or a local SVG set.
• You need tree-shaken, per-icon optimised SVG delivery, or a set that keeps growing → blade-ui-kit/blade-icons with local SVG sets is more flexible and better maintained.
• Your front end is React/Vue/Svelte → use the native eva-icons package client-side rather than server-rendered Blade components.
• You need glyphs outside Eva's inventory (~490 icons, two variants) or expect new additions over time — the upstream set is in maintenance mode.
• You require active feature development, a roadmap, or vendor engagement from the dependency. This is a small, maintenance-oriented package; expect compatibility patches, not capability.
• Accessibility is a hard requirement with no team capacity to enforce it → the package adds no accessible names by default; every icon is decorative unless your wrapper and call sites handle labelling deliberately.

How to Pitch It (Stakeholders)

For executives: This is a low-risk, zero-cost (MIT-licensed) dependency that gives our Laravel application a consistent, professional-looking icon set without design spend, licensing fees, or an added front-end build step. The v2.2.0 release is purely a Laravel 13 compatibility update — no breaking changes, no migration work, no new surface area — so it keeps us current on framework upgrades at no cost and no schedule impact. It is commodity infrastructure, not a strategic bet: it buys us speed on internal tools and dashboards and is straightforward to replace if our brand needs change.

For engineering: Adds Blade components backed by the Eva Icons set (~490 glyphs in outline and fill variants), installed via Composer only — no npm/Vite footprint, no runtime JavaScript, inline SVG rendered server-side. v2.2.0 adds explicit Laravel 13 support (PR #15, first-time contributor @arjanvanrees): a patch-level constraint change with no API changes and no deprecations, so treat it as a routine upgrade-window bump. Two caveats to record: upstream Eva Icons is largely static, and the package is in maintenance mode — budget it as a stable utility, not something that will grow with us. Engineering should also note the operational specifics: always wrap the package in a single internal <x-ui.icon> component so the eva-icons- prefix never leaks into templates, enforce sizing centrally (the SVGs ship with no default dimensions and will stretch or collapse in flex layouts), default to aria-hidden="true" and push accessible labels onto the surrounding control, drive colour through currentColor/text-* utilities rather than fill attributes, and run php artisan view:cache during deploy and view:clear when debugging stale icons. The variant suffix (-outline / -fill) is mandatory and is the most common "component not found" cause. If we later need custom iconography or tree-shaken SVG delivery, migrate to blade-ui-kit/blade-icons with local SVG sets — the wrapper boundary keeps that swap contained to a single file.