Weave Code
Blade Evil Icons Laravel Package
codeat3/blade-evil-icons
Blade Evil Icons provides easy, expressive Blade components for the Evil Icons SVG icon set in Laravel. Drop icons into your views with a simple x-evil-icon tag, control size and color via attributes, and keep your markup clean without extra JavaScript or asset pipelines.
A package to easily make use of "Evil Icons" in your Laravel Blade views.
Frequently asked questions about Blade Evil Icons
- How do I install codeat3/blade-evil-icons in a Laravel app?
- Run composer require codeat3/blade-evil-icons. Laravel package auto-discovery registers the Evil Icons set as Blade components, so no service provider edits are needed. There is no config file to publish and no migrations, routes, or middleware involved. You can render icons immediately after Composer finishes.
- What Blade syntax do I use to render an Evil Icon?
- Use the x-evil-o component and pass the icon name, for example <x-evil-o name="search" class="w-4 h-4" />. The package registers Evil Icons under the evil-o prefix through blade-ui-kit/blade-icons. Any attributes you add are passed through to the inline SVG output.
- Does blade-evil-icons support Laravel 11, 12, and 13?
- Release 1.7.0 added Laravel 13 support, but the exact composer.json constraint was not supplied in the evaluation, so verify it before upgrading. The package tracks framework majors reactively, meaning a new Laravel release can land before a compatible icon release. Check the constraint against your production, staging, and CI lock files. Confirm the range still includes whichever Laravel version your app runs.
- Can I change icon size and color with Tailwind classes?
- Yes. Because the components emit inline SVG, you can pass Tailwind or any CSS classes through the class attribute, such as w-4 h-4 and text-blue-500. Icons inherit currentColor, so text color utilities work as expected. No JavaScript or runtime sizing logic is involved.
- Do I need npm, Vite, or a build step to use this package?
- No. It is a Composer-only dependency and requires no npm, Vite, or asset pipeline. Icons are rendered as inline SVG at Blade render time. That keeps setup minimal but also means there is no per-icon code splitting or tree-shaking.
- Is codeat3/blade-evil-icons safe to use in production?
- Treat it as a commodity presentation-layer dependency, not critical-path infrastructure. It has one maintainer, zero stars, and zero dependents, which is a maintenance-trajectory signal rather than a quality verdict. Functionally the 1.7.0 release is compatibility-only with no API changes, so risk from that release is negligible. For customer-facing use, validate your lock file constraints and keep an exit path.
- How is this different from blade-ui-kit/blade-icons or other icon packages?
- This package is a thin wrapper over blade-ui-kit/blade-icons that registers the Evil Icons SVG set as Blade components. You could use the base package and register the Evil Icons set yourself. Other icon families ship as similar Blade packages if you need a larger or more actively maintained set. Evil Icons is small and effectively static, so switching families later means editing every template that used it.
- Can I add accessibility attributes like aria-hidden or a title to the SVG?
- Components output bare inline SVG, and the supplied evaluation did not confirm whether aria-hidden, role, title, and focusable can be expressed through attribute passthrough. Test these attributes in your own templates before relying on them in customer-facing UI. You should also confirm that inline SVG fits your Content-Security-Policy.
- What happens if the package is abandoned, and can I vendor the SVGs?
- No documented exit path was supplied, but because it is a thin wrapper over blade-ui-kit/blade-icons, the practical fallback is to vendor the SVG set or re-register the evil-o prefix yourself. That keeps existing x-evil-o tags working without the package. Confirm license and attribution obligations for redistributing Evil Icons in shipped product before you rely on that route.
- Does inline SVG from this package hurt page performance on icon-heavy views?
- Blade renders every icon you include as inline SVG, so there is no tree-shaking or per-icon code splitting. Icon-dense pages will see HTML payload growth compared with sprite sheets or external SVG files. Measure the impact on your busiest templates before adopting it broadly.
Weaver
How can I help you explore Laravel packages today?