Blade Tabler Icons Laravel Package

Technical Evaluation

Architecture fit. secondnetwork/blade-tabler-icons is a thin, presentational dependency. It registers a directory of ~2,400+ SVG files with blade-ui-kit/blade-icons and exposes them as anonymous Blade components (<x-tabler-alert-circle />) or via the @svg() directive. It touches no routing, persistence, queue, auth, or domain layer, so architectural fit is effectively "does the team render Blade templates?" If yes, it slots in with zero coupling to application logic. It is equally usable in Livewire views and in plain Blade; for an Inertia/SPA frontend it degrades to a static asset source via the published raw SVGs, which is a weaker but workable mode.

The real dependency is Blade Icons, not this package. All behaviour that matters — component resolution, @svg, default classes/attributes, and the icon cache — is inherited from blade-ui-kit/blade-icons. This package is a curated and continuously re-synced asset dump plus a service provider registration. That materially lowers technical risk (the engine is a mature, widely used library) and simultaneously lowers the package's unique value: we are adopting it for the icons and the automation, not for engineering.

Integration feasibility. High. composer require plus an optional vendor:publish for config is the whole install. No migrations, no env vars, no build step (the SVGs ship pre-built; the Bun build chain is upstream-maintainer-only). PHP 8.0+ / Laravel 9+ per the README, with explicit Laravel 12 and 13 support committed in v3.30.1 and v3.40.1 respectively. A spike should confirm the constraint resolution against our pinned blade-icons and Laravel versions before we plan anything.

Technical risk. Ranked:

License posture is clean: MIT on both this package and Tabler Icons, no attribution burden beyond retaining the license file.

Key questions for the maintainer/spike.

1. Does composer why-not cleanly resolve against our Laravel and blade-icons pins today?
2. What actually happens at render time for an unknown icon name — exception, empty SVG, or silent fallback?
3. Is the weekly GitHub Action fully unattended, or is there a human review gate on renames and fixes?
4. Does the package ship the filled variants at full parity with outline, and is that parity guaranteed per release?
5. What is blade-icons' cache invalidation contract after a version bump, and does the maintainer document it?
6. Which subset of the ~2,400 icons do we actually need — is the breadth a benefit or just deploy weight?

Integration Approach

Stack fit. Native. Any Laravel 9–13 application rendering Blade gets first-class support. Tailwind works cleanly because Tabler icons are stroked SVGs that inherit currentColor; the README's own examples (class="w-6 h-6 text-gray-500", style="stroke-width: 1.25") are Tailwind-shaped. Livewire is a non-issue. Inertia/Vue/React consumes it only as published static SVGs or via an icon-name-to-path endpoint — do not promise component ergonomics to a non-Blade frontend.

Migration path. Effectively none required, and that is the package's strongest selling point. This is an additive presentational layer: nothing to backfill, no data model, no dual-write, no cutover window. Two adoption shapes:

• Greenfield or icon-inconsistent codebase: adopt directly, then sweep existing inline/inline-SVG icons opportunistically per feature.
• Existing icon system (Heroicons via Blade UI Kit, Lucide, Font Awesome): do not run a big-bang swap. Icon swaps are cosmetic, unowned, and endless. Scope it to a design-system decision — pick one set, use this package only if Tabler wins that comparison, and migrate page-by-page as files are touched.

The reverse migration is the cheapest we will ever see: delete the Composer line and any now-dangling component tags. That asymmetry — trivial to adopt, trivial to abandon — is the core argument for accepting the bus-factor risk.

Compatibility. Pin explicitly on both axes:

• Laravel: 9.x supported per README; 12.x and 13.x explicitly committed. Our target version determines the floor.
• blade-icons: transitive; audit composer.lock before and after, since a major there changes component resolution and the @svg signature.
• PHP 8.0+ declared, though the README badge advertises 8.2 — reconcile against our runtime.

Do not float the constraint (^3.49). Given renames ship in minor releases, use an exact pin (3.49.0) or ~3.49.0 at the tightest setting our policy allows.

Sequencing.

1. Spike (½ day, backend dev): install in a throwaway branch, resolve constraints, render ten representative icons, deliberately reference a renamed icon to confirm the failure mode, and enable the icon cache.
2. Wrap before you spread (1 day): create one project-local seam — either a <x-icon name="alert-circle" /> wrapper or an Icons constants class — so upstream naming churn is absorbed in one file. This is the single highest-leverage step and the one most likely to be skipped.
3. Guardrail CI: a test that walks every icon name we reference and asserts it renders. This converts a silent 500 in production into a red build on the PR that bumps the version.
4. Cache and deploy: enable Blade Icons caching; wire the cache-clear into the deploy pipeline, not into a runbook nobody reads.
5. Pilot one surface: ship to an internal admin area, not the customer-facing funnel.
6. Roll out as files are touched. No dedicated migration project.
7. Decision review at 30 days: re-check package health (new releases, issue responsiveness, whether the automated pipeline is still green) and confirm the exit ramp is still cheap.

Operational Impact

Maintenance. Low and asymmetric. There is nothing to operate — no service, no cron, no storage. The recurring cost is upgrade supervision: releases land roughly weekly as the bot tracks upstream, and most are additive, so the honest posture is "upgrade deliberately and rarely" rather than "track upstream." Budget roughly 1–2 hours per upgrade cycle for the version bump, the CI icon-render check, and a visual diff on changed icons. The v3.36.1 release ("2,433 icons optimized and fixed") is a useful warning that icon appearance can shift in bulk without any API change — visual regression is a real, if cosmetic, maintenance category.

Support. No commercial support, no SLA, no maintainer on retainer. GitHub issues only, on a repo with 40 stars where the maintainer's responsiveness is unproven. Practically: our own engineers are first-line support, and they will be debugging blade-icons more often than this package. The Blade Icons README is genuinely good documentation and is the resource to point people at. Escalation path is "read Blade Icons source, then vendor the SVGs."

Scaling. Renders are static SVG markup inlined into HTML — no runtime computation, no external calls, no cold-start cost. Two scaling considerations:

• Inline payload. Each icon inlines its full SVG. Icon-heavy tables and navigation render fast but bloat HTML; measure before inlining hundreds per page. The published-assets route instead serves cacheable files, which trades an HTTP request for a smaller document and CDN-friendliness.
• Deploy weight. Publishing raw assets puts thousands of files into public/. Prefer the component/@svg path plus icon caching; publish raw assets only for the specific non-Blade consumers that need them.

Neither is a bottleneck at realistic scale. This will not be in anyone's capacity model.

Failure modes and detection.

The one genuinely dangerous mode is the first: an icon rename surfaces as a hard error, so a routine composer update can take down a customer-facing page. The CI guardrail in the integration plan exists specifically to move that failure from production to the pull request.

Ramp-up. Negligible for anyone who writes Blade — the README is complete enough that a developer is productive in under 30 minutes, and passing classes and inline styles is intuitive. Two things must be taught, not assumed: (1) reference icons through the project wrapper or constants file, never raw <x-tabler-*> in templates, and (2) the accessibility convention for decorative versus meaningful icons (aria-hidden="true" on decorative, a real label when the icon carries meaning). Both belong in the design-system doc and the PR template, not in tribal knowledge. There is no training programme here; the risk is not that developers cannot use it, it is that they use it inconsistently and re-scatter hard-coded icon names across the codebase, quietly rebuilding the coupling we just paid to remove.

Recommendation. Adopt conditionally: pin exactly, wrap in a single project-owned seam, add a CI icon-render check, and pilot behind an internal surface. The dependency is cheap, reversible, and architecturally inert — the only things that can hurt us are the coupled-to-upstream version numbering and the single-maintainer bus factor, and both are neutralised by pinning plus a wrapper, with vendoring roughly fifty SVGs as a credible exit if the repo goes quiet.