Blade Typicons Laravel Package

Product Decisions This Supports

• Build vs. buy for icon delivery. Adopt a thin, MIT-licensed Blade wrapper instead of funding an internal SVG pipeline. Engineering spend shifts from icon plumbing — sprite generation, component registration, sizing conventions — to product surfaces. The package is nearly free to try and cheap to exit: copy the roughly fifteen SVGs we actually use, change one line in our wrapper, delete the dependency. That asymmetry is the entire buy case, and it makes this a low-regret decision rather than a bet.
• UI feature velocity on Blade surfaces. Unblocks navigation, buttons, status badges, tables, empty states, notifications, and dashboard chrome in admin panels, internal tools, and MVPs — the surfaces where visual polish drives adoption but dedicated design-engineering headcount isn't justified. Composer install plus auto-discovery means a first icon in a view within minutes.
• Design-system standardization without a design system. Enforces one icon API across views, one controlled size scale, and one place where intent maps to artwork (save → tick, next → arrow-right). Views reference meaning, not pictures. That single config map becomes both the restyle lever and the usage inventory — the list we'd work from if we ever had to extract and walk away.
• Roadmap triage on icon coverage. Typicons is a compact utility set (~336 glyphs, no brand marks, no illustrations, no multi-tone). Auditing the real screens we're building against the vendor SVG directory takes an afternoon and tells us whether "icons" is a task or a project. It also tells us to budget for a handful of hand-rolled SVGs as exceptions instead of discovering a missing "upload cloud" mid-sprint.
• Cross-surface consistency. Server-rendered Blade with no JS runtime means the same component renders in HTML, Livewire components, mailables, and PDFs. That's usually where icon systems fragment — transactional email and exports drift to a second source of truth. Here they don't (with inline styles for mail/PDF, since those environments strip stylesheets).
• A compliance decision we own, not inherit. The wrapper is MIT; the Typicons artwork carries its own CC BY-SA-family license, which typically means attribution. The package's MIT license reads as "no strings attached," and that reading is wrong for the icons. Someone on the product side has to decide whether we can satisfy attribution and where the obligation lives durably — a LICENSES.md, an about screen.

When to Consider This Package

Adopt when:

• The stack is Laravel + Blade on Laravel 10–13, and we want icons in views without a build step or a JS icon runtime.
• The need is a compact utility set — nav, buttons, status indicators, table toolbars, empty states — not brand marks, illustrations, or multi-tone art.
• We commit to the wrapper-first rule on day one. All views use <x-icon name="..." />; nothing uses raw <x-typicon-*> tags. That one discipline is what converts vendor risk into a one-file swap.
• No single icon is business-critical. The failure mode here is silent — a typo'd or renamed icon renders nothing, with no exception and no log entry — so a missing glyph should degrade layout, not break a workflow.
• We pin the version in the same commit as the install and treat upgrades as deliberate acts (^1.8.0 only after confirming the PHP floor and illuminate/* constraints install cleanly; otherwise ^1.7.0). Zero stars, zero dependents, one maintainer.
• We can satisfy the artwork attribution requirement, or the surfaces are internal-only and the obligation is documented.

Look elsewhere when:

• Dependency-risk policy forbids single-maintainer, zero-dependent packages on anything customer-facing or revenue-adjacent. Note that the durable layer is blade-ui-kit/blade-icons; this package is a content pack on top, so switching sets later is cheap — but choosing a better-maintained set up front is cheaper.
• Coverage doesn't fit. Design wants a visual language Typicons can't match, or the product needs logos, rich illustrations, or multi-tone. Running two icon systems costs more than picking one.
• The screens are icon-dense — 200-row tables, kanban boards — and we don't yet have a sprite strategy. Inline SVG volume is a rendering decision, not a package defect, but it lands on us before the first release.
• Nobody will own the silent-failure debugging tax. If there's no CI smoke test over the semantic map, the first broken icon becomes an afternoon of hunting for an error that was never thrown.
• Existing Blade Icons sets are already registered and no one wants to own prefix and namespace configuration.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed content pack layered on top of Blade Icons, a foundation we'd likely be using anyway for any icon set. It buys visible polish on internal tools, admin panels, and MVPs without adding headcount — the work shifts from icon plumbing to product surfaces. The exit cost is a couple of hours: copy the icons we actually use, change one line, drop the dependency. Two risks worth naming now: it's a single-maintainer package with no dependents, which we mitigate by pinning the version and keeping all usage behind one wrapper; and the SVG artwork carries its own attribution license, which we should confirm with brand/compliance before anything customer-facing ships.

For engineering: composer require codeat3/blade-typicons, auto-discovery, no provider registration, no config, no publish step. We build one internal <x-icon> component plus a semantic map in config, and from that point every view uses a stable API and the icon set is swappable without touching a single template. Icons are server-rendered Blade, so they behave identically in views, Livewire, mailables, and PDFs. Two things to accept up front: failures are silent, so we ship a smoke test that renders every mapped icon in CI; and we pin the version because there's one maintainer and no downstream dependents to catch problems for us.

For design/UX: Roughly 336 utility glyphs, currentColor inheritance so a parent class controls color for free, and a token map so size stays on a consistent scale instead of drifting into inline width/height attributes. A coverage audit against our real screens takes an afternoon; anything missing gets hand-rolled as an explicit exception rather than treated as a blocker.

The ask: approve adoption for internal and admin surfaces with the wrapper enforced from the first commit, pin ^1.8.0 after a compatibility check, and get a written answer on the artwork attribution obligation before we extend it to customer-facing surfaces.