Weave Code
Blade Solar Icons Laravel Package
codeat3/blade-solar-icons
Blade components for the Solar icon set, letting Laravel developers drop crisp SVG icons into views with simple x-solar tags. Multiple styles and weights, no build step or extra tooling required.
A package to easily make use of "Solar Icons" in your Laravel Blade views.
Frequently asked questions about Blade Solar Icons
- How do I install codeat3/blade-solar-icons in a Laravel app?
- Run composer require codeat3/blade-solar-icons and you are done. The package auto-discovers its service provider and registers every Solar glyph as a Blade component, so there is no config file to publish, no assets to compile, and no secrets or environment changes. You can render an icon in any Blade view immediately with an x-solar tag. Realistic time to first render is well under an hour.
- Which Solar icon styles are included in this package?
- It ships the Solar icon set in Linear, Bold, Broken, Outline, and Duotone styles. Each glyph is registered as its own Blade component, so the style is selected by the component name you call rather than by a separate configuration option. Because components are addressed by generated names, an upstream icon rename shows up as a runtime component-not-found error, so it is worth spot-checking the names you rely on after any version bump.
- How do I change the size, color, or CSS class of a Solar icon in Blade?
- Size, color, and CSS classes are all passed as component attributes on the x-solar tag, which forwards them to the rendered SVG element. That means you can style icons inline per call site or wrap them in your own Blade component for consistent design tokens across the app. Keeping those calls behind a small wrapper also keeps the vendor swap-out cost to about ten lines of code.
- Does blade-solar-icons support Laravel 11 and Laravel 12?
- Earlier releases such as 1.3.1 remain functionally correct on Laravel 11 and 12, and version 1.4.1 is the release that advertises Laravel 13 support. The real compatibility surface is not this package's own code but its blade-ui-kits/blade-icons and illuminate/* constraints, so verify what a 1.4.1 install pulls in before pinning. Run composer update codeat3/blade-solar-icons --with-dependencies --dry-run against your real lockfile and record exactly which other packages move.
- Do I need Node, npm, or a build step to use these icons?
- No. The SVGs are shipped inside the Composer package and rendered through lightweight Blade components with no runtime dependencies, so there is nothing to compile and no asset pipeline to wire up. This is the main reason to use it on a server-rendered Laravel app rather than an npm icon package. It is the wrong choice for a JavaScript SPA that already has an icon pipeline.
- How does blade-solar-icons compare to using blade-icons directly or an npm icon package?
- This package is a convenience layer on top of blade-ui-kits/blade-icons: it bundles the Solar SVG set and pre-registers each glyph as a component so you do not have to import or register icons yourself. Using blade-icons alone gives you more control but more setup, while an npm package is a better fit for a JS SPA. Avoid running two icon pipelines in one product, since that is pure maintenance tax.
- Can I use Solar icons in Blade emails, PDF invoices, or error pages?
- Yes, and that is where this package is most valuable, because those contexts often do not execute JavaScript at all. Transactional email templates, PDF invoices, error pages, CLI-generated HTML, and OG images all render Blade server-side, so inline SVG components fit naturally. It is also fine for standard web views, including Livewire and Inertia apps that render Blade on the server.
- How should I test that the Solar icon components render correctly?
- Pin the version in a branch, render around twenty icons that actually appear in your production templates, and diff the emitted SVG markup against the previous version. Functional tests will happily pass while silently regenerated or renamed icons break visually, so a markup diff catches what assertions miss. Also visit the routes that only use icons cosmetically, since a missing component throws at render time rather than at build time.
- Is codeat3/blade-solar-icons actively maintained and safe to depend on in production?
- It is a leaf presentation-layer dependency with no service surface, no persistence, and no domain code, so it cannot corrupt data or fail a migration; removal is just deleting template calls. The risks are concentration, not severity: a single maintainer across the codeat3 icon packages, a small star count, and a release history that jumps from 1.3.1 to 1.4.1 with no documented 1.4.0, which is worth checking before you pin. Treat it as a commodity convenience rather than a platform bet, and wrap it so the swap path stays cheap.
- Does blade-solar-icons work with Livewire, Inertia, or API-only Laravel services?
- It works anywhere Blade renders on the server, which includes Livewire components and Inertia apps that use Blade for the initial page shell. It is the wrong dependency for an API-only service with no views, and it is redundant in a JavaScript SPA that already pulls icons from npm. Before adopting, also confirm the upstream Solar licence permits redistributing the SVGs inside your artifacts and whether it requires UI attribution.
Weaver
How can I help you explore Laravel packages today?