Weave Code
Blade System Uicons Laravel Package
codeat3/blade-system-uicons
codeat3/blade-system-uicons adds Laravel Blade components for the System UIcons SVG icon set, letting you render lightweight, customizable icons directly in Blade views with simple tags—ideal for dashboards, menus, and UI details.
A package to easily make use of "System UIcons" in your Laravel Blade views.
Frequently asked questions about Blade System Uicons
- What is codeat3/blade-system-uicons used for?
- It adds anonymous Laravel Blade components for the System UIcons SVG icon set, so you can drop icons into views with tags like <x-system-uicons-home /> instead of pasting raw SVG markup. It is aimed at dashboards, navigation menus, buttons and small UI details where lightweight inline icons are enough. It only serves Blade-rendered output, which includes Livewire and Inertia apps whose shell is Blade, but it is not a delivery mechanism for a separate React, Vue or mobile client.
- How do I install codeat3/blade-system-uicons?
- Run composer require codeat3/blade-system-uicons and the package is ready to use. It ships an auto-discovered service provider that registers the icon set with blade-ui-kit/blade-icons, which arrives as a transitive dependency. There are no credentials, environment variables, migrations or manual provider registration steps.
- Which Laravel and PHP versions does this package support?
- Support is defined entirely by the composer constraints on laravel/framework and blade-ui-kit/blade-icons, so the exact matrix depends on the release you install. Release 1.9.0 widened Laravel 13 compatibility, but you should verify the constraint windows in your composer.lock or the package composer.json rather than trusting a changelog summary. Confirm both the Laravel and PHP floors before planning a framework upgrade.
- How do I use an icon in a Blade view?
- Reference the icon name as a component, for example <x-system-uicons-home />, and the SVG is rendered inline at that point in the markup. Component names come directly from the upstream System UIcons names, so the icon list is effectively the component list. No registration, import or compile step is needed per icon.
- Can I change the icon size, color or add CSS classes?
- Attributes such as class, style or a width and height are passed through to the rendered SVG element, so you can size and color icons with your existing utility or component CSS. Because the output is inline SVG, standard CSS techniques apply the same way they would to hand-written SVG. There is no theme or config layer to override; styling is done at the call site or in your stylesheet.
- Do I need to publish a config file for this package?
- No. The package has no configuration surface, no database tables, no queue or cache backend and no API of its own. Adding or removing it does not touch domain code, so it can be adopted or dropped without a data migration or refactor.
- How does it handle accessibility for icon-only buttons?
- The package renders the icon markup; labelling the control is still your responsibility. For icon-only buttons and links you should supply an accessible name, for example an aria-label on the button or a visually hidden text span, plus visible focus styling from your own components. Check the aria-hidden and title defaults on the rendered SVG during your accessibility pass and override per component where needed.
- How should I test these icons in CI?
- Add a render test that exercises the icon components used in your layouts, so a missing or renamed component fails in CI instead of at render time in production. Upstream icon renames surface as missing-component errors rather than build failures, which makes this test the main safety net. A single icon-dense page plus an accessibility check is a reasonable pilot scope.
- Does it work with config:cache and view:cache in a deploy pipeline?
- Caching is a known failure point for icon packages, so smoke-test your deploy with config:cache and view:cache enabled rather than assuming it works. The package itself introduces no cache backend of its own, but the interaction with Blade component resolution under cached views is worth an explicit check in staging. Also watch payload size, since icons inline as SVG and icon-dense pages inflate HTML output.
- What are the main risks of adopting this package?
- The biggest risk is version coupling: the package must stay inside the constraint windows of laravel/framework and blade-ui-kit/blade-icons, and a lagging release can block your framework upgrade rather than just your icons. It is also a single-maintainer package with a very small dependent base, so there is little ecosystem evidence to borrow confidence from. The blast radius stays small because the payload is inert SVG markup, which makes vendoring the icon directory or forking a low-cost contingency.
Weaver
How can I help you explore Laravel packages today?