Blade Feather Icons Laravel Package

Getting Started

Install and confirm which tag the package actually registers before writing any markup:

composer require brunocfalcao/blade-feather-icons

Then read two things in vendor/brunocfalcao/blade-feather-icons/:

1. The service provider — to see the component alias/namespace (x-feather-icon, x-feather::, or a Blade::component registration) and whether a config file is published.
2. The resources/ or svg/ directory — to confirm the exact icon filenames (camera.svg, camera-off.svg), since names map 1:1 to files and typos fail at render time, not at build time.

Your first use case should be a single decorative icon in an existing layout:

<x-feather-icon name="camera" class="w-5 h-5 text-gray-500" />

If that throws "component not found", try the namespaced form (<x-feather::camera />) or the directive form (@svg('feather-camera', 'w-5 h-5')) — the package's docs and provider are the source of truth here. Clear compiled views (php artisan view:clear) after installing, then move on to wrapping it (see below) rather than scattering raw tags across your views.

Implementation Patterns

Wrap it once, use it everywhere. Given the package's size (36 stars, single maintainer), the most valuable pattern is a thin app-level wrapper so you can swap the underlying package later without touching 200 views:

{{-- resources/views/components/icon.blade.php --}}
@props(['name', 'size' => 'w-5 h-5'])
<x-feather-icon
    :name="$name"
    {{ $attributes->merge(['class' => "$size shrink-0"]) }}
    aria-hidden="true"
/>

Then <x-icon name="trash" class="text-red-600" /> is your only public API.

Map semantics, not icon names, in config. Keep a translation table so product language stays out of templates:

// config/icons.php
return [
    'nav.dashboard' => 'grid',
    'status.paid'   => 'check-circle',
    'status.failed' => 'x-circle',
    'action.delete' => 'trash-2',
];

<x-icon :name="config('icons.status.'.$invoice->status)" /> keeps a single choke point for renaming or restyling icons.

Buttons and nav items. Feather is stroke-based with currentColor, so the idiom is to let the parent set color and use flex for spacing:

<button class="inline-flex items-center gap-2 text-sm font-medium text-white">
    <x-icon name="plus" class="w-4 h-4" />
    New project
</button>

Build an icon picker for your team. Because names are filenames, a dev-only route that globs the SVG directory and renders them in a grid pays for itself immediately. Cache the file list (Cache::remember('feather-icons', now()->addDay(), ...)) — a glob()/File::files() per request is wasteful if you render hundreds of icons.

Testing. Assert on the rendered <svg> presence plus the icon's distinguishing path fragment, not the whole markup (whitespace and attribute order are brittle):

$this->get('/dashboard')->assertSee('feather', false)->assertSee('name="camera"', false);

Better: assert your wrapper renders (assertSee('<svg', false)) and cover icon-name selection in a unit test over the config map.

Gotchas and Tips

• Stroke, not fill. Feather icons use fill="none" stroke="currentColor" stroke-width="2". Coloring with fill-* or text-fill-* does nothing; use text-{color}, and adjust weight with stroke-width (pass it as an attribute if the component forwards $attributes).
• Don't set width/height attributes alongside Tailwind sizing. The package's SVGs typically carry hardcoded width="24" height="24". If those leak through, your w-5 h-5 fights the attribute. Verify the wrapper actually merges $attributes onto the <svg> root — if the component drops them, that's the first thing to patch (or fork the view and publish it).
• Unknown names fail loudly or silently. Depending on implementation you get an exception, an empty <svg>, or a 500. Add a fallback in the wrapper (file_exists check or a try/catch returning a neutral help-circle) so a typo in a config map doesn't take down a page.
• Accessibility is on you. Decorative icons need aria-hidden="true" (put it in the wrapper). Meaningful standalone icons need role="img" plus a <title> — most icon packages don't emit one, so add a <x-icon-label> variant for anything that isn't accompanied by visible text.
• Compiled views and publishes. After vendor:publish (config/views) or a package upgrade, run php artisan view:clear && php artisan config:clear. Published views shadow the vendor ones permanently — note it in your README so the next dev doesn't debug stale SVGs.
• Pin the version. This is a low-velocity, low-signal package. Use a caret constraint on the minor you tested, keep the dependency isolated behind <x-icon>, and you can swap to blade-ui-kit/blade-feather-icons, codeat3/blade-feather-icons, or a local SVG directory with a one-file change if it goes unmaintained.
• Feather's set is frozen. No brand logos (GitHub, Slack, Stripe) and no new icons are coming upstream. For brands, keep a tiny local resources/svg/brands/ directory and render those with @svg rather than fighting the icon package.
• Repetition cost. Rendering the same icon 100× in a table means 100 inlined SVGs. It's usually fine, but if the HTML gets heavy, switch that view to an SVG sprite (<symbol> + <use>) — the icon package won't do it for you.
• Livewire. Re-rendered components re-emit the SVG each time; nothing breaks, but keep icons out of the parts of the DOM you're morphing needlessly if payload size is a concern.