Blade Teeny Icons Laravel Package

Product Decisions This Supports

• Where iconography lives: template vs. bundle. Adopting this package commits any surface that uses it to server-rendered inline SVG rather than a build-time asset. That's a small but directional architectural call. Make it deliberately — because retrofitting it into a design-system story later means a migration, not a toggle.
• Deferring an owned icon pipeline. This is a thin Blade wrapper over the Teeny Icons set (same author family and conventions as blade-heroicons / blade-tabler-icons). Choosing it is effectively deciding not to build an icon source of truth this quarter. Reasonable if no design-system package is on the roadmap; if one is, adopting this now creates a planned migration rather than eliminating work.
• Whether to fund server-rendered surfaces at all. The strongest product case is surfaces a JS bundle can't reach: queued mailables, PDF invoices, Blade error pages, Livewire/HTMX fragments, server-rendered admin panels. If those are on the roadmap, this removes a real obstacle. If they aren't, the case shrinks to "one fewer npm dependency" — a weaker justification for a dependency decision.
• Laravel 13 upgrade sequencing. Release 1.12.0 is compatibility-only (a single PR: "laravel 13 compatibility"). Treat it as risk clearance, not roadmap progress — it keeps this package off the upgrade-blocker list. Don't let it appear on a status deck as delivered value.
• Payload budgeting for icon-dense views. Inline SVG is not deduplicated: a page rendering the same icon fifty times ships fifty SVG bodies. This forces a decision on dashboards, settings pages, and data tables — accept the payload, cache rendered fragments, or consolidate repeated icons. Quantify on your densest screen before rollout, not after.
• Buy-vs-wrap calibration. The avoided work is modest — a component, an icon registry, and a config publish is roughly half a day of engineering. Frame adoption as maintenance convenience and convention consistency, not effort saved. The "we'd have to build this ourselves" argument does not survive scrutiny at this scale.
• Dependency-register hygiene. Zero stars and zero dependents is a signal about breadth of production use, not code quality — but it belongs in the register as unvalidated externally, single maintainer, so future reviewers inherit the context rather than rediscovering it.

When to Consider This Package

Adopt when:

• Laravel with Blade as the primary rendering layer, and you want icons as first-class components with no npm/Vite step for iconography.
• You need icons where a JS bundle cannot run — transactional email, PDF generation, error pages, server-rendered fragments. This is the most defensible use case and the one to lead with.
• You standardise on Tailwind or utility CSS and want class, size, and colour passthrough so styling stays in existing conventions instead of a parallel icon API.
• You already use (or plan to use) other codeat3/blade-* icon packages — shared conventions make a multi-set setup low-friction.
• You want a deliberately narrow, uniform visual language — consistent minimal glyphs for dense admin/dashboard and settings UIs. The constraint is the feature.
• Upgrade headroom matters and you want one fewer entry on the Laravel 13 blocker list.
• Reversibility matters more than depth. Adoption is composer require plus an optional config publish; rollback is a one-line revert.

Look elsewhere when:

• You need bespoke, multicolour, branded, or animated iconography. Teeny Icons is a single deliberate minimal style and won't stretch to brand illustration work.
• You need thousands of icons with tree-shaking or per-icon code-splitting. An npm icon package with a bundler plugin gives materially better payload control than inline Blade SVGs.
• You already have a mature icon pipeline — an internal sprite build or design-system package. A second source of truth is a net negative at any licence price, including free.
• You aren't rendering Blade — Inertia/React/Vue SPAs, API-only services, or anywhere the component has no surface to render on.
• Governance requires vendor backing or a security disclosure process. This is community-supported with a single maintainer; record it accordingly.
• You require an actively evolving icon set. Recent history is compatibility bumps only; assume low-velocity upstream and plan so new icon requests don't become a surprise.
• You need a support guarantee that survives maintainer unavailability. Icons are static SVG, so forking or vendoring is a realistic escape hatch — but someone must own that contingency before adoption, not after.

How to Pitch It (Stakeholders)

For executives: We're evaluating a small, free, MIT-licensed Laravel package that gives our Blade templates a consistent set of minimal icons. The value is operational rather than novel: it removes a Node/Vite dependency for iconography, lets us render the same icons in emails, PDFs, and error pages where a JavaScript bundle can't run, and — as of this release — it's confirmed compatible with Laravel 13, so it won't hold up our framework upgrade. Cost is effectively zero and lock-in is low, because the icons are static files we could vendor ourselves if needed. Two cautions: the icon set is intentionally narrow, and the project is single-maintainer with low release velocity. Treat it as a convenience dependency for server-rendered surfaces, not as our sole long-term icon source.

For engineering leads: This is a thin Blade-component wrapper over the Teeny Icons SVG set, following the same conventions as blade-heroicons and blade-tabler-icons, so there's no new mental model. Release 1.12.0 contains exactly one change — Laravel 13 compatibility — with no API changes, deprecations, or breaking changes. Adoption is a composer require plus optional config publish; rollback is a one-line revert. Three things to agree before we commit: (1) icons are inlined into HTML and not deduplicated, so use on-demand components and fragment caching on icon-dense pages rather than bulk preloading; (2) if iconography later moves into a bundled front-end pipeline, this becomes duplicate tooling — pick one source of truth now; (3) confirm whether 1.12.0 widens the framework constraint or replaces it, and that CI actually runs against Laravel 13 rather than only declaring it. Also check for component-name collisions if other icon packages are installed.

Recommendation: Adopt as a low-commitment, low-risk convenience dependency for server-rendered surfaces, gated on a sub-day spike that confirms class passthrough, caching behaviour, payload impact on our densest page, and the constraint semantics of the 1.12.0 change. Revisit if we standardise iconography in a design-system package, if upstream misses a Laravel major compatibility release, or if we need iconography beyond a single minimal style.