Blade Solar Icons Laravel Package

Product Decisions This Supports

Icon-system standardisation. codeat3/blade-solar-icons turns the Solar icon set (thousands of glyphs across linear, bold, outline, broken, bold-duotone, and linear-duotone styles) into auto-registered Blade components (<x-solar-home-linear />). It resolves the recurring "which icon library do we standardise on?" question for any Laravel Blade surface — marketing site, admin panel, customer portal — with one Composer line instead of a design-export pipeline.

Build vs. buy. Adopting is materially cheaper than maintaining an in-house SVG sprite sheet plus a Blade wrapper. Because components are generated from the upstream Solar set, new icons arrive on composer update rather than a design-to-dev handoff. This is a clear "buy" (adopt) on a convenience capability, so engineering capacity stays on differentiating work. Explicitly not building: an icon-component layer, an SVG optimiser, or an accessibility wrapper — all absorbed here.

SSR and no-JS surfaces. Icons render as inline SVG at request time, so they work in transactional email, invoice PDFs, OG images, error pages, and CLI-generated HTML — paths a React/Vue icon package cannot serve without hydration. This is a genuine product unlock: consistent iconography across surfaces that a JS-based icon system simply cannot reach.

Roadmap sequencing for the Laravel 13 upgrade. v1.4.1 adds Laravel 13 compatibility, which removes this package as a blocker in the framework-upgrade workstream. If Laravel 13 is on the roadmap, this dependency can be cleared now rather than deferred. The release is compatibility-only; no feature work is gated on it.

Theming and white-labelling. Because icons are Blade components with pass-through attributes, colour, size, and theming ride on CSS custom properties or Tailwind classes — supporting white-label variants and dark mode without a second icon set or parallel asset pipeline.

Low-cost reversibility. This is a leaf presentation dependency; upstream SVGs are freely copyable. An "adopt now" decision carries minimal lock-in — if maintenance lapses, swapping the source is a thin-wrapper change, not a rewrite.

When to Consider This Package

Adopt when:

• The stack is Laravel + Blade (or Livewire/Inertia rendering Blade server-side) and you want icons with zero configuration — auto-discovery, published config optional, no build-tool plugin.
• You need breadth (thousands of icons) with a consistent visual language, not a hand-curated set of 30.
• Icons must appear where JavaScript does not run: transactional email, PDF invoices, OG images, error pages.
• You are on, or migrating to, Laravel 13 — v1.4.1 keeps this dependency current; on Laravel 11/12 Composer resolves 1.3.1 with an identical component API, so templates don't change either way.
• You want an MIT-licensed, Composer-only dependency that passes a standard security/procurement review without a vendor contract.
• You are standing up a design system and want a thin wrapper component (<x-icon name="..." />) as the single point of control for naming, sizing, and aria-hidden defaults.

Look elsewhere when:

• The frontend is a JS SPA (React/Vue/Svelte) where icons belong in the component tree and need tree-shaking; a PHP package adds nothing, and running two icon pipelines is a maintenance tax.
• You need only a handful of bespoke/brand icons — inline SVG or a small local Blade component is simpler than a multi-thousand-icon dependency.
• Page weight is critical and you render hundreds of icons per view — each usage emits full inline SVG, so HTML payload grows; an SVG sprite with <use> references is leaner at that scale.
• You need icon-font workflows (glyph ligatures, content: CSS) or Figma-plugin round-tripping.
• Strict dependency minimalism applies (e.g., regulated environments with a hard dependency-count ceiling) — the value here is convenience, not unique capability.

Diligence before pinning: single-maintainer project with an auto-generation pipeline; the 1.3.1 → 1.4.1 jump with no documented 1.4.0 warrants a direct tag/CHANGELOG check. Run a --dry-run composer update against the real lockfile to confirm the Illuminate constraint broadens rather than raises, verify the icon-naming map didn't change, and check the upstream Solar licence terms suit distribution and attribution needs. Treat it as a convenience layer over upstream assets.

How to Pitch It (Stakeholders)

For executives: A free, MIT-licensed Laravel package that gives every screen a complete, visually consistent icon set with no design or engineering overhead. The 1.4.1 release adds Laravel 13 support, so it is not a blocker for the framework upgrade and requires no migration work from us. Cost is one Composer line plus roughly an hour of developer setup; the alternative is owning an icon pipeline we would have to build and maintain. Risk is low and reversible: it is a presentation-only dependency, and because we will isolate it behind our own wrapper component, we can swap the icon source later without touching feature templates.

For engineering: Zero-config Blade components — <x-solar-{name}-{style} /> with styles linear, bold, outline, broken, bold-duotone, and linear-duotone; attributes pass through so sizing, colour, and Tailwind classes work as expected. Renders inline SVG server-side: no JS bundle cost, and it works in email/PDF/SSR paths. v1.4.1 is a compatibility-only release with no API changes, no deprecations, and is non-breaking; on Laravel 11/12 Composer resolves 1.3.1 with an identical component API. Caveats: single-maintainer, generated package — pin the version, enable the manifest/sprite cache in production to avoid boot-time directory scanning, and keep icons behind a thin wrapper component (<x-icon name="..." />) so the source can be swapped without touching call sites. Before pinning, run a --dry-run composer update against the lockfile and render-diff a sample of production icons to catch silent SVG regeneration.