Weave Code
Blade File Icons Laravel Package
codeat3/blade-file-icons
A Laravel Blade package for rendering file-type icons directly in your templates. Drop-in components make it easy to show icons for documents, images, archives, code files, and more, with simple customization for size and style.
A package to easily make use of "File Icons" in your Laravel Blade views.
Frequently asked questions about Blade File Icons
- How do I install codeat3/blade-file-icons in a Laravel application?
- Install it with Composer using composer require codeat3/blade-file-icons. The package registers its service provider through Laravel's package auto-discovery, so the Blade components are available immediately after installation. There is no publish step, no configuration file to create, and no asset build required. You can start using the icons in any Blade view right away.
- Which PHP and Laravel versions does blade-file-icons support?
- Compatibility is defined by the php and illuminate/support constraints in the package's composer.json at the tag you install. Release 1.11.0 was a single-line change adding Laravel 13 support, which means a constraint widening rather than a rewrite. Check that file before upgrading your framework to confirm which Laravel majors and PHP floor are still covered. Older majors are only guaranteed if they remain inside those constraints.
- How do I render a file icon in a Blade view?
- Use the package's Blade component tag for the file type you want, or the @svg directive exposed by the underlying Blade Icons renderer. Both output inline SVG markup directly in your template, so no HTTP request or image asset is involved. The exact component names are listed in the package's icon index.
- Do I need npm, Vite, or asset compilation to use blade-file-icons?
- No. The package ships SVG artwork that is rendered inline by Blade, so there is no npm dependency, no Vite step, and no publishing of assets to public/. This also means the icons inherit CSS from your stylesheet and can be styled with utility classes. The trade-off is that the SVG markup is part of your rendered HTML rather than a cached external file.
- How do I change the size or color of a file-type icon?
- Because the icons are inlined as SVG, you control them with CSS or utility classes such as Tailwind's h-6, w-6, and text-gray-500 applied to the component or its wrapper. Any attributes you pass to the component are forwarded to the rendered SVG element. CurrentColor-based artwork will follow your text color automatically.
- Does blade-file-icons work alongside blade-ui-kit/blade-icons or heroicons?
- Yes. This package is part of the codeat3/blade-icons family and is built on blade-ui-kit/blade-icons, so it shares the same rendering path as other icon sets such as heroicons or tabler. If Blade Icons is already in your stack, adoption adds no new mechanism. If it is not, installing this package pulls in that dependency chain for what is a fairly narrow visual need.
- What happens if an icon for a file extension does not exist in the set?
- Missing icons fail silently: a renamed or removed glyph in a future minor release produces absent markup rather than an exception. There is no runtime error to alert on, so regression detection depends on visual smoke tests or assertions on rendered HTML. If icon coverage matters for a file table, add a Blade test that asserts the expected SVG output for your key extensions.
- How many icons ship with the package, and will it slow down large file tables?
- The package bundles a broad set of file-type SVGs, which adds install size but not runtime cost for icons you never render. What does cost something is per-row component instantiation: rendering an icon for every row in a large file table inflates the markup your server produces. Measure the actual rendered output for your heaviest page before rolling it out across an icon-dense listing.
- Is blade-file-icons safe to add to a production Laravel application?
- Architecturally yes. It is a pure presentation-layer package that registers a service provider exposing Blade components, with no controllers, models, migrations, routes, queues, or environment variables that could hold state or fail at runtime. The caveats are operational rather than structural: a single maintainer with a small user base, constraint coupling that can gate future Laravel major upgrades, and silent visual regressions on icon renames. None of those are blockers for a bounded cosmetic concern with a trivial removal path.
- Should I use blade-file-icons or just vendor the SVG icons myself?
- If you already use blade-ui-kit/blade-icons and expect to need a wide and growing vocabulary of file-type icons, the package is close to free and gives you consistent naming. If you only need a handful of glyphs, copying ten SVGs into resources and keeping your own component names is an afternoon of work with zero dependency risk. Factor in that the package has a single maintainer and few dependents, so vendoring is a legitimate hedge rather than a criticism.
Weaver
How can I help you explore Laravel packages today?