Weave Code
Blade Clarity Icons Laravel Package
codeat3/blade-clarity-icons
codeat3/blade-clarity-icons is a Laravel Blade package for using Clarity Icons in your views. It provides simple Blade components to render any Clarity icon as inline SVG, making icons easy to add, style, and customize in PHP applications.
A package to easily make use of Clarity Icons in your Laravel Blade views.
Frequently asked questions about Blade Clarity Icons
- How do I install codeat3/blade-clarity-icons in a Laravel app?
- Install it with Composer by running composer require codeat3/blade-clarity-icons. The service provider is auto-discovered, so there is nothing to register in config/app.php, and publishing the optional config file is entirely optional. After that you can use the components immediately in any Blade view without migrations, environment variables, or a build step.
- Which Laravel and PHP versions does this package support?
- The package targets Laravel 10 and newer, and release 1.11.0 was a compatibility bump that added Laravel 13 support. The PHP floor is declared in the package's composer.json and generally tracks what your Laravel version requires, so check that constraint before upgrading a platform major. Always confirm the exact version range in the package's composer.json rather than assuming, since 1.11.0 could either widen the constraint or replace older majors.
- How do I render a Clarity icon in a Blade view?
- Use the package's Blade component syntax, for example <x-clarity-home />, anywhere in your Blade templates. Each component compiles to an inline SVG at render time, so the icon inherits the page's CSS and requires no separate asset request. Component names map to the Clarity icon catalog bundled with the package, so use the name matching the icon you want.
- Can I change the component prefix or choose a different icon set?
- Yes. The package ships an optional config file that lets you control the component prefix and icon-set selection, which you publish with the standard vendor:publish command. Most projects keep the default clarity prefix and do not need to publish the config at all. If you do customize the prefix, document it in your project conventions so other developers do not guess at component names.
- How do I style or resize the inline SVG icons?
- Because the icons render as inline SVG, you can style them with regular CSS or utility classes, and attributes you pass to the component such as class, style, width, height, and aria-hidden are applied to the SVG output. For theme-aware coloring, set the SVG fill to currentColor so the icon follows the surrounding text color. Add aria-hidden="true" for decorative icons and a title or aria-label for meaningful ones.
- Does this package require JavaScript, npm, or a front-end build step?
- No. It ships no runtime JavaScript and has no asset-pipeline footprint, so there is nothing to compile, publish, or bundle. Icons are inlined into the rendered HTML by Blade at request time, which means they work even in applications with no Node toolchain at all. The only cost is slightly larger HTML on icon-dense pages.
- Does it work with Livewire and Inertia?
- It works in Livewire views because Livewire still compiles Blade components server-side, so the x-clarity components render normally. It is not useful in Inertia or other SPA front-ends that render icons client-side, since the Blade components never execute in that setup. It is also a poor fit for API-only services that do not render Blade views.
- How does it compare to blade-ui-kit/blade-icons?
- blade-ui-kit/blade-icons is a generic icon-component engine where you register icon sets, including Clarity; this package is a ready-made Clarity-specific wrapper with the set already bundled. Choose one and record that choice, because running both creates overlapping component namespaces and ambiguous resolution order that tends to surface only in production. If your application already standardizes on blade-icons with a Clarity set registered, this package adds nothing.
- How should I test that the icons render correctly?
- Write a feature or view test that hits a page using the component and asserts the SVG markup appears in the response, for example with assertSee on a distinctive path or class in the SVG. Where the rendering is complex, a snapshot or assertSee(..., false) check on the raw SVG is a cheap regression guard. Also cover any version bump in CI, since the bundled SVGs are pinned and visual drift only arrives on deliberate upgrades.
- Is the package well maintained, and what are the upgrade and supply-chain risks?
- It is effectively a single-maintainer package with no commercial SLA, so the dominant long-term risk is abandonment rather than defects, and adoption should be a recorded architectural decision rather than an incidental dependency. Version pinning and testing each bump mitigates most of the exposure, and the blast radius of a delayed Laravel major bump is your whole upgrade, not just the icons. Before clearing dependency review, audit the embedded SVGs for scripts or external references, since the icon set is bundled and pinned rather than fetched from VMware upstream.
Weaver
How can I help you explore Laravel packages today?