Blade Radix Icons Laravel Package

Product Decisions This Supports

• Commoditizing the icon layer, once, deliberately. The highest-leverage PM move here is to stop letting icons be a per-squad decision. Adopting this package declares Radix Icons the house default for Blade-rendered surfaces — a cheap, reversible standard that removes a recurring "which SVGs do we paste?" conversation from every UI review. The value isn't the icons; it's the de-duplication of a decision that otherwise gets relitigated.

• Framing the real build-vs-buy fork. The comparison is never "package vs. free." It's "package vs. a bespoke <x-icon> wrapper plus an SVG directory plus perpetual upkeep," or "package vs. inlining the 15–20 glyphs we actually use." All three are defensible; the PM job is to pick one and cap the debate. If the design system consumes fewer than ~20 icons, inlining is genuinely the lower lifetime cost — say so and move on.

• A dependency-hygiene line item, not a roadmap input. Release 1.9.0 is a single Laravel 13 constraint bump (PR #22) — no new icons, no API change, no deprecations. If Laravel 13 is on the roadmap, this package can come off the "upgrade blocker" list. Treat it as a one-line risk note in the planning doc, never as a review agenda item.

• Unblocking feature surfaces. Internal admin panels, back-office tooling, authenticated dashboards, and static Blade marketing pages get crisp, currentColor-inheriting glyphs with no JS icon runtime and no sprite-sheet maintenance. That's a small but real velocity unlock for server-rendered UI.

• Explicitly not a differentiator. Icons are commodity infrastructure. The PM's job is to make the call fast, keep it out of design-system debate bandwidth, and refuse to let a 2-star presentation dependency absorb sprint capacity.

• Setting the boundary condition up front. The decision this doesn't support: making this the icon path for JS-rendered surfaces. If an Inertia/React/Vue frontend appears or grows, a Blade-only wrapper fragments the icon system. Scope the adoption to Blade views and record that constraint now, not after the second frontend ships.

When to Consider This Package

Adopt when:

• The surface is Blade-first and server-rendered — admin panels, internal tools, back-office, static marketing — with no competing React/Vue/Inertia icon pipeline.
• The design language is neutral and utility-grade. Radix Icons is a general-purpose, monochrome, 15px-optimized set; it is not a brand asset and shouldn't be pitched as one.
• We want first-class component syntax (<x-radix-icon-name />) with zero build step, zero JS bundle weight, and no sprite maintenance.
• Laravel 13 is planned or current; 1.9.0 declares support for it.
• We accept the maintenance profile: single maintainer, releases driven by upstream icon syncs and framework bumps, MIT assets we could vendor out in an afternoon.
• We're comfortable being an early adopter — 2 stars and zero dependents mean we should verify behavior rather than assume community vetting.

Look elsewhere when:

• Brand-specific, multi-color, or illustrative iconography is required — this is a utility glyph set.
• The frontend is predominantly Inertia/React/Vue with an established icon component library; a Blade-only wrapper would fragment the system.
• Procurement requires vendor SLAs, security attestation, or long-term support — a solo-maintainer package won't clear that bar.
• Accessibility obligations demand a managed semantics layer (labeling policy, aria-hidden conventions, RTL). The components are thin; audit the emitted markup before broad rollout.
• The design system needs fewer than ~20 icons — vendor those SVGs directly.
• We need sprite/caching mode for icon-dense pages and can't configure it without forking.

Three gates before committing broadly: (1) composer require --dry-run resolves cleanly on the target Laravel 13 skeleton — note that Laravel 13 support only holds if blade-ui-kit/blade-icons itself resolves there, so a green release here is necessary but not sufficient; (2) smoke tests assert representative icon components render non-empty SVG, because missing icons fail silently; (3) view:cache runs after composer install in deploys, or production renders blank icons.

How to Pitch It (Stakeholders)

Executives (30 seconds): We're evaluating a free, small open-source add-on that gives our Laravel app a standard, ready-made icon set — the small glyphs used on every screen. It replaces custom icon code we'd otherwise write and maintain ourselves, needs no build tooling, and its latest release confirms compatibility with the Laravel version we plan to adopt. Cost is effectively zero. The one caveat is that it's maintained by a single volunteer; if it ever stalls, the icons are open-source and swapping them out is roughly an afternoon of work. Recommendation: adopt now for internal, admin, and back-office surfaces; revisit before making it load-bearing in customer-facing UI.

Executives (if pressed on the 2-star count): Stars measure community size, not code risk. This is a packaging-only dependency — a service provider plus a directory of SVGs, no runtime services, no data, no network calls. Our exposure is a handful of glyphs in rendered HTML, and the exit cost is low because the assets are MIT and vendorable under the same component names. The risk we're accepting is maintenance continuity, not blast radius.

Engineering: This is codeat3/blade-radix-icons — a thin Blade component wrapper over the Radix Icons SVG set, built on the blade-ui-kit/blade-icons ecosystem. No migrations, no queues, no config keys, no published assets; it's a presentation-layer dependency resolved at view-compile time. Release 1.9.0 is a single-change release: a Laravel 13 constraint update. No new icons, no API changes, no deprecations — upgrading from 1.8.0 is routine version hygiene, and it marginally improves our risk profile by keeping us on a supported framework path.

The trade we're stating plainly: we accept a small amount of dependency risk — single maintainer, upstream-driven content, infrequent releases — in exchange for deleting a bespoke SVG component layer. That trade is favorable if we keep usage scoped to Blade views and don't let it become the icon path for JS-rendered surfaces.

Three things to verify before broad rollout:

1. Resolvability. Run composer require codeat3/blade-radix-icons:^1.9 --dry-run against the Laravel 13 skeleton and capture the full dependency delta. The real constraint is transitive — Laravel 13 support only holds if blade-icons and the implied PHP floor also resolve.
2. Silent failures. Add smoke tests asserting a handful of representative icon components emit non-empty <svg> markup. Unknown or renamed components render empty markup rather than throwing, so defects otherwise land in visual QA instead of CI.
3. Accessibility. Confirm rendered markup meets our conventions — decorative icons hidden, meaningful icons labelled.

Guardrails: pin the version (^1.9 plus committed lockfile, automated via Dependabot/Renovate, CI as the gate); keep a documented list of icons we actually use so a swap is mechanical; run view:cache after composer install in deploys; and don't couple the package bump to the framework upgrade in the same PR — land the framework change first, then the near-no-op package bump.

On optimization: HTML weight is the only scaling dimension, and it's compile-time markup, not a service. For icon-dense pages, evaluate blade-icons sprite/caching mode — but treat that as a separate, measured performance change after the framework upgrade is stable, not as part of adoption.

Exit plan: if the maintainer goes dormant, this degrades rather than breaks. Publish the SVGs into resources/ under the same component names and carry on. Record that decision now so it never becomes a blocker.