Weave Code
Blade Fluentui System Icons Laravel Package
codeat3/blade-fluentui-system-icons
Render Microsoft Fluent UI System Icons in your Laravel Blade views with simple, fluent components. Browse the full icon set and drop crisp, scalable SVG icons into your app with a single tag.
A package to easily make use of FluentUI System Icons in your Laravel Blade views.
Frequently asked questions about Blade Fluentui System Icons
- How do I install codeat3/blade-fluentui-system-icons in a Laravel app?
- Install it with Composer by running composer require codeat3/blade-fluentui-system-icons. Laravel's package auto-discovery registers the service provider, so in most setups there is nothing else to do. There are no migrations, published assets, or scheduled jobs involved, and you can start using the components immediately after the autoloader is refreshed.
- Which Laravel and PHP versions does this package support?
- Release 1.35.0 added Laravel 13 support as a single-purpose compatibility change with no breaking changes or deprecations. Teams on Laravel 10 through 12 are not forced to do any work by that release. Because the release note does not spell out whether older framework versions, the blade-icons floor, or the PHP minimum changed, you should read the composer.json constraints on the exact tag you are installing, especially in a monorepo with mixed framework versions.
- Do I need to install blade-icons or publish a config file to use this package?
- No manual setup is required in a typical installation. The package ships FluentUI System Icon SVGs as assets and registers them into the blade-icons ecosystem, exposing them as Blade components. There is an optional publishable config file, but it is only needed if you want to customize behavior such as the component prefix.
- What is the Blade syntax for rendering a FluentUI System Icon?
- Icons are rendered as Blade components using the fluentui prefix, for example a single self-closing tag that names the icon you want. The output is a crisp, scalable inline SVG, so you can size and color it with normal CSS classes. Because the components come from blade-icons, the syntax matches Heroicons, Tabler, and Phosphor wrappers you may already use.
- Can I change the component prefix or naming convention for the icons?
- Yes, the prefix is configurable through the package's optional config file, which you can publish into your application. Treat that decision as a template API: once teams start writing the tags across views, changing the prefix later becomes a repo-wide find-and-replace plus review churn. Get design and engineering sign-off on the naming convention before the first merge.
- Will this package conflict with Heroicons or other blade-icons packages in my app?
- They generally coexist because each package registers its own component prefix, so Heroicons, Tabler, and FluentUI icons can live side by side in the same views. The one caveat is version constraints on blade-icons itself. If a bump to this package raises the blade-icons floor, every other icon package in the application moves at the same time, so review those updates together rather than in isolation.
- Why did my icon suddenly render as an error after a Composer update?
- Icon names follow Microsoft's FluentUI upstream inventory, so a minor release can rename or remove a glyph without any change to the PHP code. That fails at render time, typically as a 500, with no compile-time warning or build failure to catch it. Pin the package version, review its changelog before upgrading, and cover the icons you actually use with a render test in CI.
- How do I test that FluentUI icons render correctly in CI?
- Write a smoke test that renders every icon component your views actually reference and asserts a successful response containing an SVG element. This catches renamed or removed glyphs that would otherwise only surface as a 500 in production. Running it on the same matrix as your framework versions also guards against blade-icons constraint changes.
- Is this package safe to use in production and does it hurt performance?
- For a decorative, view-layer dependency the risk is low: there is no runtime configuration, no service-layer hooks, and a defect is confined to template rendering, where the fallback is inlining the SVGs you need. Each icon is an inline SVG, so there is no extra HTTP request, but a large volume of SVG files does land in vendor and gets pulled into every build and deploy artifact. Keep it off critical paths and treat it as presentation only.
- Is codeat3/blade-fluentui-system-icons well maintained, and what are the alternatives?
- It is a single-maintainer package with a small adoption footprint, so the bus factor and lack of community issue history are real caveats to log rather than ignore. On the positive side, the maintainer tracks Laravel majors, which is the most valuable durability signal for a small dependency, though timely Laravel 13 support is a point-in-time fact and not a promise about Laravel 14. If your design system is not standardizing on Fluent UI, the alternatives are simply other blade-icons wrappers or inlining the handful of SVGs you need.
Weaver
How can I help you explore Laravel packages today?