Weave Code
Blade Weather Icons Laravel Package
codeat3/blade-weather-icons
Easily add Weather Icons to Laravel Blade views with this lightweight component package. Install via Composer and use simple x-weather-icon tags to render scalable, customizable icons anywhere in your templates, with no manual SVG handling required.
A package to easily make use of "Weather Icons" in your Laravel Blade views.
Frequently asked questions about Blade Weather Icons
- How do I install codeat3/blade-weather-icons in a Laravel app?
- Install it with Composer by running composer require codeat3/blade-weather-icons. The package registers itself through Laravel package auto-discovery, so no manual service provider registration is required. Once installed, the weather icon Blade components are immediately available in any of your templates. There are no assets to publish and no build step involved.
- Which Laravel versions does blade-weather-icons support?
- Release 1.8.0 is a single-change release that adds Laravel 13 compatibility, with no new features or documented breaking changes. Whether that means the illuminate/* constraints were widened or replaced matters, so check the composer.json in the 1.8.0 tag rather than relying on the changelog line. If the constraints were replaced rather than widened, teams still on Laravel 10 through 12 should stay on the 1.7.0 line. Confirm Laravel 13 actually resolves in your environment before adopting it ahead of need.
- What is the correct Blade syntax for rendering a weather icon?
- The package description advertises an attribute-based form like <x-weather-icon name="day-sunny" />, while developer notes show a per-icon tag like <x-weather-icon-day-sunny />. That ambiguity is a known documentation inconsistency, so treat the shipped SVG filenames as the source of truth instead of the README. Blade Icons conventions mean both styles are worth testing, but verify which one your installed version actually resolves. Agree the naming convention with your team early so the first developer to use it does not set the precedent by accident.
- Do I need to publish configuration or register a service provider?
- No. The package has no configuration surface, no publishable assets, and no settings to tune, because it only bundles a static SVG set and registers it with blade-ui-kit/blade-icons. Composer install plus Laravel auto-discovery is the entire integration. That zero-configuration footprint is also why replacing it later is a view-layer refactor rather than a migration.
- Can I resize or style weather icons with Tailwind CSS?
- Yes. The Blade components accept standard HTML attributes, so class, width, height, and other utility props pass through to the rendered SVG. That makes them compose cleanly with Tailwind or any other utility styling framework. Because the icons render as inline SVG, they scale without quality loss and inherit currentColor where the source markup allows it.
- Is codeat3/blade-weather-icons safe to use in production?
- The technical risk is low because the package holds no business logic, makes no external service calls, and its failure mode is cosmetic rather than commercial. The real caveat is adoption signal: roughly one star and no known dependents means it is unproven in production anywhere, so you would be an early validator. It also has a single maintainer, a bus factor of one, though the exit is cheap because the SVG set can be inlined into your repository in an afternoon. Write that contingency down so it is not rediscovered mid-incident.
- Are the weather icon components accessible to screen readers?
- Accessibility behavior is not documented, so do not assume the components emit aria-hidden, role, or title attributes correctly. Verify the rendered markup in your own environment and wrap the icons in a single project-level component that enforces your accessibility contract. Doing this once, before icons spread across templates, is far cheaper than retrofitting dozens of views later. Purely decorative icons should be hidden from assistive technology, while meaningful ones need a text alternative.
- Can I ship only a curated subset of Weather Icons instead of the whole set?
- The package bundles and registers the full Weather Icons SVG set rather than offering documented pruning. If payload size or naming sprawl is a concern, define an allowlist in your own wrapper component and reference only the icons you have approved. You can also inline the handful of SVGs you actually use and drop the dependency entirely, which is the documented escape hatch.
- How should I test weather icons in my Blade views?
- Because the components render plain SVG markup, standard Blade assertions such as assertSee and assertSeeHtml cover them without extra tooling. Assert on the icon name or a stable class rather than exact SVG path data, which changes when the upstream icon set is updated. If you wrap the icons in a domain component, test that wrapper instead so your suite does not break when the underlying package is swapped out.
- What are the alternatives to blade-weather-icons, and how hard is it to switch?
- It occupies the same tier as Blade Heroicons, Blade Font Awesome, or a hand-rolled sprite sheet, so the choice is mostly about which icon vocabulary you want centralized. Switching means replacing component tags in your templates or inlining the SVGs, which is a view-layer refactor rather than a migration. To keep that exit cheap, wrap the icons in your own component and keep the provider-to-icon-name mapping, such as OpenWeather 01d, in one place you control.
Weaver
How can I help you explore Laravel packages today?