Weave Code
Blade Element Plus Icons Laravel Package
codeat3/blade-element-plus-icons
A Laravel Blade package that makes Element Plus icons available as simple, ready-to-use Blade components. Install via Composer and render scalable SVG icons in your views with clean, expressive tags, no manual SVG copying required.
A package to easily make use of "Element Plus Icons" in your Laravel Blade views.
Frequently asked questions about Blade Element Plus Icons
- How do I install codeat3/blade-element-plus-icons in Laravel?
- Install it with Composer by requiring codeat3/blade-element-plus-icons; Laravel package auto-discovery registers the service provider, so no manual provider entry is needed. There is no config file to publish, no migrations, and no credentials or queues involved. Realistic effort is under an hour to your first rendered icon. Render one icon in a low-risk view to confirm auto-discovery before rolling it out across the codebase.
- Which Laravel versions does this Element Plus icons package support?
- Release 1.2.0 widened the illuminate/support ceiling so the package supports Laravel 10 through Laravel 13, and it is additive and backwards compatible for Laravel 12 and below. Because the tightest compatibility surface is the illuminate/support plus blade-ui-kit/blade-icons constraint pair, run composer why-not immediately after bumping to see what is blocking you. If a Laravel major upgrade is in flight, sequence this package last so constraint conflicts surface in isolation rather than inside the framework-upgrade pull request.
- What component prefix do Element Plus icons use, x-ep-plus or x-element-plus?
- The documentation references both x-ep-plus-* and x-element-plus-*, so do not pick one from the docs alone. Resolve it empirically by listing the components that are actually registered in your install, which takes about a minute. Then write the confirmed prefix into your style guide as a permanent convention. This matters because roughly a thousand components register globally under a single prefix.
- Do I need Node, Vite, or a build step to use Element Plus icons in Blade?
- No. The package vendors the Element Plus SVG set and registers it with blade-ui-kit/blade-icons, so icons render as Blade components with no JavaScript runtime, no Node toolchain, and no asset compilation. It is orthogonal to your front-end build, which makes it safe whether the app is Blade with Alpine, Blade with Livewire, or Blade with Inertia. The only real dependency is the blade-icons constraint pair in Composer.
- How do I render an Element Plus icon inside a Blade view?
- Use the registered component tag with the icon name, for example an edit icon rendered through your confirmed prefix. Attributes you add to the tag pass through to the underlying SVG element. Confirm the exact name casing by listing registered components rather than guessing. Once a couple of tags render correctly, codify the convention so the team does not mix naming styles.
- Can I use this package alongside Heroicons or Font Awesome?
- Yes. Icon packs built on blade-ui-kit/blade-icons register independently, so multiple packs can coexist in one application. The practical approach is coexistence-first: install this package, use its prefix only for new work, and convert high-traffic views in batches. Retire the old pack once its usage hits zero, and remember that rollback is just composer remove plus reverting component tags, with no schema or data changes.
- How do I cache Blade icons for production performance?
- Add the php artisan blade:icon-cache command to your deploy pipeline and CI so the SVG set is resolved once rather than per request. At roughly a thousand registered components, measure cold render performance and confirm the cache command covers the full set at that scale. Keep the cache step ordered correctly relative to your view and config caching. If you notice slow boots, that is the first thing to check.
- Are the rendered Element Plus SVG icons accessible to screen readers?
- It is not documented whether the rendered svg emits aria-hidden or focusable attributes, so assume you need to handle it until you verify the actual markup. Inspect one rendered icon in your browser to see what attributes are present. Decorative icons should be hidden from assistive technology, while meaningful icons need an accessible label, typically by wrapping the component and supplying a title or aria-label. Verify this before shipping customer-facing interfaces.
- Do new Element Plus icons appear automatically when the upstream set updates?
- No. The set is a manual re-sync of @element-plus/icons-vue, so new upstream glyphs lag until the maintainer regenerates and tags a release, and there is no SLA on that gap. If you depend on a newly added icon, check the package release history before planning around it. For anything urgent, you can vendor the SVG yourself or open an issue upstream. Treat the icon vocabulary as versioned, not continuously synced.
- Is this package safe to use in production given its low adoption?
- Technical risk is low in absolute terms: it is a presentation-layer asset bundle with no service to run, no JS, and no migrations. However, it has one star and zero dependents, so there is effectively no third-party validation, and you should treat it as a convenience dependency rather than a foundational one. Lock the version in composer.lock, keep the MIT notice intact, and know your abandonment contingency. Because the package is a swappable vocabulary layered on blade-icons, replacing it with another icon pack or hand-rolled partials is a contained change, and the real architectural commitment is to blade-icons itself.
Weaver
How can I help you explore Laravel packages today?