Blade Tabler Icons Laravel Package

Getting Started

1. Install with Composer and let package discovery do the rest:

   composer require jb-sommeling/blade-tabler-icons
   

   There is no service provider to register manually and, for the common case, nothing to publish. Run php artisan about (or composer show jb-sommeling/blade-tabler-icons) to confirm the package is picked up after install.

2. Look here first when you need to understand behaviour:

   • vendor/jb-sommeling/blade-tabler-icons/resources/views/components/ — the generated icon Blade components; this is the authoritative list of available icon names.
   • vendor/jb-sommeling/blade-tabler-icons/config/ — any publishable config (size/stroke defaults, component prefix).
   • The package README for the exact component naming convention, since icon names map to component tags.

3. First use case — drop an icon into an existing Blade view:

   <x-tabler-home class="w-5 h-5 text-gray-500" />
   

   The component renders inline SVG, so normal utility classes and $attributes (id, data-, aria-, wire:*) pass through to the root <svg> element. That makes it a drop-in replacement anywhere you were previously pasting raw SVG.

4. Sanity check: render one icon, then php artisan view:clear. If the tag renders as literal text, the component namespace isn't registered — you're on a version/framework combination that isn't supported (see gotchas).

Implementation Patterns

Wrap it once, use it everywhere. Rather than repeating size and colour classes, create a thin project component (resources/views/components/icon.blade.php) that forwards to the package component with your design-system defaults. This gives you a single place to change stroke width or sizing later, and insulates your views if the package's tag convention ever changes.

Navigation and menu configs. Because the tag is static, the usual friction is rendering icons from data. Two workable approaches:

• Store the icon name in config (['label' => 'Dashboard', 'icon' => 'home']) and render with Blade::render("<x-tabler-{$item['icon']} class=\"w-4 h-4\" />"), or
• Map names to components in a small Icon view component that switches on the name.

Prefer the second in hot paths — Blade::render compiles a new string each call and is measurably slower in loops.

Consistent sizing via CSS, not props. Tabler icons are stroke-based SVGs. Setting width/height through Tailwind classes (w-4 h-4, w-5 h-5) keeps them aligned with your type scale and avoids the icon drifting when you change font sizes. Avoid mixing pixel attributes and classes.

Pair with view:cache in production. These are ordinary Blade components, so php artisan view:cache during deploy precompiles them. On a large icon set this is the difference between a fast first request and a slow one.

Compose into higher-level components. Buttons, links, and empty states that always show an icon are the natural boundary:

<x-button>
    <x-tabler-plus class="w-4 h-4 -ml-1 mr-2" />
    {{ $slot }}
</x-button>

Testing. Assert on rendered output with $this->blade('<x-tabler-home />') and check for <svg plus the expected path count, rather than snapshotting the full SVG — icon artwork changes between Tabler releases and brittle snapshots will churn.

Gotchas and Tips

Version pinning matters for Laravel 13. v1.0.1 is the release that added Laravel 13 support. If you're on Laravel 13, you need ^1.0.1 — earlier versions will fail dependency resolution or, worse, install against a framework they weren't tested with. If you're on Laravel 10–12 you can stay on ^1.0, but there's no reason to hold back; the release contains no breaking changes.

v1.0.1 also hardened the CI and build script. The icon components in this package are generated from the upstream Tabler icon set. A build-script change means the generated output can differ from v1.0.0 in ways the changelog doesn't enumerate. After upgrading, do a visual diff on a handful of icons in a real page, and always run php artisan view:clear — stale compiled views from the old component set are the most common "the upgrade broke my icons" report.

Component names are kebab-cased and can collide. Icon names like arrow-up-right map cleanly, but names that overlap with your own app components (e.g. a project <x-tabler-logo>) will silently shadow or be shadowed depending on registration order. Prefix your own components or publish/rename the package namespace if you hit this.

$attributes land on the <svg>, not a wrapper. That's usually what you want, but it means class="..." from your call site merges with the component's internal classes. If you set fill-* utilities on an outline icon you'll get unexpected results — outline and filled variants are distinct icon sets, not a style toggle.

Accessibility is on you. The SVGs are decorative by default. For meaningful icons add aria-hidden="false" plus a <title>, or an adjacent visually-hidden label. Don't rely on the icon alone to convey state (e.g. a red icon meaning "error").

Wholesale icon replacement is the extension point. If you need to customise an icon, don't patch vendor/. Either publish the package views (if supported) and override the specific component, or define a same-named component in your app to take precedence. Patching vendor files is lost on the next composer update.

Watch the stroke-width. At small sizes (w-4) the default stroke can look heavy or muddy, particularly on dense UIs and at 1x DPI. Setting a slightly thinner stroke globally in your wrapper component is usually better than editing icons individually.

Debugging a tag that won't render: check php artisan view:clear, confirm the icon name exists in the vendor components directory, and confirm the package's Laravel constraint is satisfied by your composer.lock. Anonymous components fail silently to an unresolved tag rather than throwing, so a literal <x-tabler-...> in the output is almost always one of those three.