Blade Remix Icon Laravel Package

Getting Started

Install

composer require andreiio/blade-remix-icon

No service-provider registration or migrations are required on Laravel 7+ — the package registers its Blade components via auto-discovery. There is typically nothing to publish unless you want to override the icon directory or prefix, so most apps ship with just the composer.json line and a lockfile bump.

Where to look first

1. vendor/andreiio/blade-remix-icon/resources/svg (or icons/) — this is the source of truth for valid names. Remix names are filenames, including the style suffix, e.g. home-line.svg, home-fill.svg, arrow-left-up-line.svg.

2. vendor/andreiio/blade-remix-icon/README.md — confirm which component shape your version exposes. Most releases follow the blade-icons convention, so you render:

   <x-remix-home-line />
   

   If your version wraps everything in a single component, it will be:

   <x-remix-icon name="home-line" />
   

3. config/blade-remix-icon.php (if published) — prefix, path, and default class overrides.

First use case

Put one icon into an existing view with Tailwind sizing to confirm the pipeline works end-to-end:

<x-remix-home-line class="size-5 text-gray-500" />

Then grep for the SVGs you already inline by hand (nav, buttons, empty states) and swap them out — that is usually a 20-minute win that shrinks your templates and removes copy-pasted <svg> blobs.

Implementation Patterns

Two variants, one name. Remix ships every icon as *-line (outlined) and *-fill (solid). Treat the suffix as a prop in your own abstractions rather than duplicating callsites:

@props(['name', 'variant' => 'line'])
<x-dynamic-component :component="'remix-'.$name.'-'.$variant" {{ $attributes }} />

Wrap it in a design-system component. Do not sprinkle <x-remix-*> with ad-hoc classes across 200 views. Create resources/views/components/icon.blade.php that owns sizing, color, and accessibility defaults:

@props(['name', 'size' => 'size-5'])
<span {{ $attributes->class($size) }} aria-hidden="true">
    <x-dynamic-component :component="'remix-'.$name" class="size-full" />
</span>

This gives you one place to swap the icon set later and one place to enforce aria-hidden.

Decorative vs. meaningful icons. Purely decorative icons need aria-hidden="true" and the adjacent text label. Standalone icon buttons need an accessible name:

<button type="submit" aria-label="Delete">
    <x-remix-delete-bin-line class="size-4" aria-hidden="true" />
</button>

Dynamic icons from data. Menu configs, DB-driven navigation, and CMS blocks commonly store an icon name string. Use x-dynamic-component and keep the name list constrained (see Gotchas):

<x-dynamic-component :component="'remix-'.$item->icon" class="size-4" />

Color is inherited, not set. Remix SVGs use currentColor. Set color on the parent with text-* utilities or CSS; passing fill="..." on the component will be ignored or fight the SVG internals.

Hot paths. If a layout renders 40+ icons per request, benchmark before optimising. For extreme cases, render icons once into a hidden SVG sprite with @once and reference them with <use>, or cache the rendered HTML fragment — Blade component resolution is not free at that volume.

Testing. Icons are inline SVG, so assertions are straightforward:

$this->get('/')->assertSee('remix-home-line', false); // or assertSeeHtml

If you expose the design-system wrapper, assert on your own component name instead so tests survive an icon-set swap.

Emails and PDFs. Because the SVG is inlined into the HTML, this works in mail templates — but many email clients strip inline SVG. Have a PNG fallback or use an icon font for mail only.

Gotchas and Tips

• Names must match filenames exactly. A typo yields Unable to locate a class or view for component rather than a helpful "icon not found". When debugging, ls vendor/andreiio/blade-remix-icon/resources/svg | grep home is faster than guessing.
• Remix naming is not perfectly systematic. You will find home-2-line, arrow-left-up-line, menu-2-fill, and chat-1-line alongside plain home-line. Do not assume a naming pattern when generating icon names programmatically.
• Never pass raw user input into the component name. If the name comes from a DB column or request parameter, an attacker-influenced string ends up in a component/file lookup. Validate against an allowlist of filenames discovered from the vendor directory, or store an enum.
• Hard-coded width/height on the SVG root. Some icons carry explicit dimensions that can beat utility classes depending on specificity. Prefer wrapping the icon in a sized <span> and letting the SVG fill it (class="size-full"), or strip attributes with $attributes->merge() — check the rendered output in the browser rather than trusting the source.
• Attribute bag merging. Classes passed to the component land on the <svg> root. If your wrapper also sets classes, use $attributes->class([...]) so callers can override without duplication.
• Caching. In production php artisan view:cache and config:cache are fine, but after composer update of the package, clear compiled views if you published or overrode any icon templates.
• No IDE autocomplete for names. Add a config/icons.php (or a PHP enum) enumerating the ~20–60 icons your app actually uses. It documents intent, powers validation, and makes the eventual icon-set migration a mechanical change.
• Maintenance risk. 18 stars and no linked repository means bus factor is effectively one. Pin the version in composer.json ("andreiio/blade-remix-icon": "^1.0"), and keep your wrapper component thin — if the package stalls, dropping raw SVGs into resources/views/components/ behind the same <x-icon> API is a half-day migration, not a rewrite.
• Extension point. Because this is a Blade-icons-style package, you can usually register additional icon paths or a second prefix in a service provider, letting you add custom brand marks alongside Remix without forking. Check Blade::componentNamespace / the published config before writing your own loader.
• Bundle cost. Inlined SVGs are not cacheable assets and repeat on every render. If the same icon appears on every page, either accept the few hundred bytes or move to a sprite; do not ship a 2,800-icon set to the browser just because it's available server-side.