- How do I install technikermathe/blade-lucide-icons in a Laravel app?
- Install it with composer require technikermathe/blade-lucide-icons. The service provider is registered automatically through Laravel package discovery, so no manual wiring is needed, and an optional config file can be published if you want to customize behavior. There are no migrations, no assets to compile, and no runtime infrastructure to configure.
- Does blade-lucide-icons require Node, npm, or a build step?
- No. The package renders Lucide icons as inline SVG directly from Blade, so there is no JavaScript dependency, no npm install, and no asset compilation involved. If you are building a decoupled SPA with Vue or React, you should use the lucide or lucide-react npm packages instead, since this package adds no value to a client-side build pipeline.
- Which Laravel and PHP versions does this package support?
- The package targets Laravel 9 through 12 on PHP 8.x and works in any Blade-rendered application. Confirm your installed Laravel and PHP versions against the package's Composer constraints before committing. Because the v3 line ships frequent minor releases driven by upstream icon syncs, check the constraint for the specific version you plan to adopt.
- How do I use a Lucide icon inside a Blade view?
- Drop a component tag such as <x-lucide-arrow-right /> into any Blade template and the icon renders inline as SVG. Livewire components and server-rendered Inertia pages work the same way because everything happens during Blade rendering. No directive registration or manual includes are required.
- Can I control icon size and color, and does it work with Tailwind?
- Yes. Because icons are emitted as inline SVG, they inherit the current text color and can be sized with classes or attributes, which makes them straightforward to pair with Tailwind utilities. You can pass Tailwind classes such as h-5 w-5 or text-blue-600 directly on the component. If icons appear stale after deploying, run php artisan view:clear since Blade view caching can mask changes.
- Do the icons work with Livewire and server-rendered Inertia?
- Yes. Both Livewire and server-rendered Inertia pages go through Blade, so the x-lucide-* components render normally. The only case where the package is the wrong layer is a fully decoupled SPA doing client-side rendering, where you should consume Lucide from npm instead.
- Why did my x-lucide-* icon break after a composer update?
- Lucide is a community-maintained icon set that periodically adds, renames, and removes icons, and each icon maps to a Blade component name. A routine composer update that syncs a newer Lucide release can therefore silently break references to names that changed upstream. Pin the package version, review the Lucide changelog between sync points, and verify icon renders in a canary environment before promoting to production.
- Should I pin blade-lucide-icons to an exact version in composer.json?
- Yes, a tight constraint such as 3.192.* is safer than a floating ^3.0. The v3 line is at minor 192, which reflects a sync-driven release train with hundreds of individually low-impact updates per major version. Pin the package, run composer update for it deliberately, and include php artisan view:clear in your deployment steps.
- How do I migrate from Feather or Heroicons to blade-lucide-icons?
- Migrating from Feather is largely mechanical name mapping since Lucide descends from Feather, making it the lowest-friction path. From Heroicons or FontAwesome, expect a semantic remapping exercise rather than a rename, so budget design time for reviewing icon-to-meaning choices instead of just replacing strings. Introducing a thin internal wrapper component such as <x-icon name="..." /> before broad adoption keeps upstream names in exactly one map.
- Is this package production-ready given it is maintained by a single developer?
- It is MIT licensed, widely usable, and technically low risk to integrate, but it is a small, largely single-maintainer project, so bus factor should be acknowledged. The practical mitigations are to pin the version, keep application code behind an internal icon alias component with an explicit allow-list, and treat icon syncs as deliberate reviewed events. Because the SVGs can be vendored into your own codebase, exit cost is bounded if maintenance ever stops.