Weave Code
Blade Majestic Icons Laravel Package
codeat3/blade-majestic-icons
Blade Majestic Icons brings the Majestic icon set to Laravel as simple Blade components. Render crisp SVG icons anywhere in your views with a clean, consistent tag syntax, keeping markup readable and styles easy to customize.
A package to easily make use of Majestic Icons in your Laravel Blade views.
Frequently asked questions about Blade Majestic Icons
- What is codeat3/blade-majesticons and what does it do?
- It is a Laravel package that exposes the MIT-licensed Majesticons SVG icon set as anonymous Blade components. An auto-discovered service provider registers a component path pointing at a vendored folder of SVG files, so each icon renders inline into your HTML response. It contains no domain logic, persistence, routes, or runtime services, which means it is purely a presentation-layer convenience dependency.
- How do I install codeat3/blade-majesticons in a Laravel application?
- Run composer require codeat3/blade-majesticons and let Laravel package auto-discovery register the service provider. There is nothing to publish and no configuration file that changes application behaviour. After the Composer install completes you can reference the icon components directly in any Blade view.
- How do I render an icon in a Blade template?
- Each SVG file in the package maps to a Blade component named after that icon, so you render it with a self-closing component tag such as the home icon. Check the README icon listing for the exact component prefix and available names before writing templates, since the names are free strings derived from the filenames. The markup stays readable and no sprite include or asset helper is required.
- Which Laravel versions does this package support?
- Support is delivered as minor-version releases, and version 2.3.0 widened the illuminate/* constraint to cover Laravel 13 via PR #13. Because bumps arrive after each Laravel major ships, there is a gap window on every future upgrade where the package may not resolve. Pin the package per Laravel major and sequence the bump as a line item in your framework upgrade epic, before the framework bump itself.
- Can I control icon size and color with Tailwind classes?
- Yes. The icons are inlined as SVG, so they inherit currentColor and respond to Tailwind text-* utilities for color. You can set dimensions with w-* and h-* classes and layer dark: or group-hover: variants on the same element. This is the main reason to prefer inline Blade components over pulling icons in through Vite or an SVG sprite.
- Does codeat3/blade-majesticons work with Inertia, React, or Vue front ends?
- No. The package only produces server-rendered Blade components, so in an Inertia, React, or Vue-only front end the components never render. It also does not apply to non-Laravel services. If your UI is client-rendered, use a JavaScript icon package or an SVG sprite instead.
- Is it safe to drive icon names from CMS content or API data?
- No, not without guards. Component names are unvalidated free strings, so a typo surfaces as a runtime unable to locate a class or view for component exception rather than a build failure. In data-driven usage such as CMS menus, notification types, or nav tables this becomes a latent defect class. Constrain icon names behind an enum or allow-list before shipping that pattern, and treat it as a prerequisite rather than a follow-up.
- Is the package well maintained, and what is the bus factor?
- It has effectively one maintainer, no SLA, and no escalation route, with a release cadence driven entirely by Laravel releases. The project has zero stars and zero dependents, so there is essentially no community validation behind it. Treat it as a convenience dependency with a documented escape hatch rather than a platform commitment, and record an owner and pin policy on your dependency inventory.
- What is the fallback plan if the package stalls on a future Laravel major?
- Vendor the SVG files you actually use into your own resources folder as a documented fallback. From there you can wrap them in local anonymous Blade components with the same tag names, which keeps call sites unchanged. Because the dependency is presentation-layer only, removal is a composer remove plus call-site cleanup, so the escape hatch is cheap to keep current.
- How does this compare to other Blade icon packages and to using a sprite?
- It is one of a large family of near-identical blade-* icon packages from the same maintainer, so the real decision is which icon family to standardise on, not which package wrapper to use. Choosing inline Blade components over a Vite-imported sprite removes a front-end build step and a sprite generation task, and keeps unused icons out of both the JS and CSS bundles. Whichever you pick, make it a documented standard so different squads do not accumulate several icon dependencies in the same codebase.
Weaver
How can I help you explore Laravel packages today?