Weave Code
Blade Akar Icons Laravel Package
codeat3/blade-akar-icons
Blade Akar Icons gives Laravel developers a simple Blade component API for rendering the Akar Icons SVG set. Install the package, then drop icon components into your views with configurable size, color, and attributes—clean inline SVGs with no manual markup or asset files.
A package to easily make use of Akar Icons in your Laravel Blade views.
Frequently asked questions about Blade Akar Icons
- How do I install codeat3/blade-akar-icons in a Laravel application?
- Install it with Composer using composer require codeat3/blade-akar-icons. The package is a presentation-layer add-on that registers Blade components, so Laravel's package auto-discovery picks it up with no manual provider registration. After that you can drop icon components straight into any Blade view. No asset build step, credentials, or migration is involved.
- How do I render an Akar icon in a Blade view?
- Each Akar icon is exposed as its own Blade component, so you render one with the x-akar- prefix followed by the icon name, for example <x-akar-heart />. The component outputs an inline SVG directly into your markup, so there are no image files to publish or sprite sheets to manage. You can also pass through standard HTML attributes such as class or id alongside the icon props.
- How do I change the size and color of an Akar icon?
- The components accept size and color props, which are applied to the rendered SVG, and you can freely mix in Tailwind or your own CSS classes for finer control. Because the output is inline SVG rather than an img tag, currentColor and CSS fill or stroke rules work as expected. For repeated usage, define a small wrapper component or a config default so styling stays consistent.
- Which Laravel versions does this package support?
- Release 1.26.0 is a compatibility-only update whose documented change is Laravel 13 support, so the package is declared compatible with modern Laravel releases. Note that the real constraint is blade-ui-kit/blade-icons, which this package wraps and does not control, so gate any framework upgrade on that dependency too. Treat the declared compatibility as unverified until your own CI has actually run against the target Laravel version.
- Do I need to publish a configuration file?
- No. The package works out of the box once installed, and publishing config is optional if you want to adjust defaults such as the component prefix or default CSS classes. Because there is essentially no runtime configuration of consequence, most projects never touch it. Skipping the config publish keeps your config directory clean and makes the dependency easier to remove later.
- Does this package make external HTTP calls or require a network connection?
- No. The Akar icon SVGs are shipped inside the package and rendered as inline markup, so there are no runtime API calls, CDN requests, or external asset fetches. That makes it safe for offline builds, air-gapped environments, and privacy-sensitive applications. It also means icon rendering adds no meaningful request latency.
- Can I use these icons in Livewire components, Inertia pages, or email templates?
- Yes for Livewire and Inertia, since the components render inline SVG in ordinary Blade views and therefore work inside Livewire component templates and Blade partials used by Inertia. For transactional email, inline SVG support varies by mail client, so test rendering in the clients you actually target or supply a fallback. Marketing pages and internal admin tooling are the lowest-risk use cases.
- How is this different from using blade-ui-kit/blade-icons directly or hand-vendoring SVGs?
- Blade Akar Icons is a thin wrapper over blade-ui-kit/blade-icons that pre-registers the Akar set, so it saves you the effort of importing icon files yourself. If you only need a handful of glyphs, roughly under ten, hand-vendoring the SVGs and skipping the dependency is often the cheaper and more controllable option. If your team already has a design system or sprite pipeline delivering icons, adding this creates a second icon convention and two upgrade paths.
- What are the maintenance and production risks of depending on this package?
- The package is a single-maintainer, low-signal dependency with a small star count, and the maintainer also carries a large family of sibling blade-* icon packages, so attention is spread. The architecture risk is genuinely low because it is a presentation-layer leaf with no database, queue, or domain surface, and removal is a view edit rather than a migration. It is fine for cosmetic chrome, but treat it as unsuitable if icons ever become semantically load-bearing or brand-critical. Also watch for upstream Akar Icons going dormant or quietly changing a glyph, which is a design-review trigger rather than a breaking change.
- How should I test that the icons actually render in my Laravel app?
- Add a simple feature test that requests a page using the component and asserts the expected SVG markup or icon class appears in the response, which catches broken registration after an upgrade. A quick manual smoke render across one or two views covers the rest. Because there is no runtime service, that rendering check is effectively the whole test surface, so keep it in CI and re-run it whenever you bump Laravel or blade-ui-kit/blade-icons.
Weaver
How can I help you explore Laravel packages today?