- How do I install codeat3/blade-elusive-icons in a Laravel app?
- Install it with Composer by running composer require codeat3/blade-elusive-icons. The package ships an auto-discovered service provider that registers the Elusive Icons set with blade-ui-kit/blade-icons, so no manual provider registration is needed. After that you can immediately use the components in any Blade view. There is no build step or asset compilation required.
- How do I use an Elusive icon inside a Blade template?
- Use the Blade component syntax, for example <x-elusive-user /> for a user glyph, wherever you would normally place an inline SVG. Each icon in the set is exposed as its own component, so you get autocompletion-friendly, readable markup instead of pasted SVG paths. The components compile to inline SVG output at render time.
- Which Laravel versions does codeat3/blade-elusive-icons support?
- The package targets Laravel applications that render views with Blade, which in practice means Laravel 9 and newer. Release 1.6.0 widened the illuminate/support constraint to permit Laravel 13, which signals intent to support that version. Note that an allowed Composer constraint is not the same as a verified CI matrix, so confirm your own test suite passes on your target framework version before upgrading production.
- Do I need to publish a config file or run any commands after installing?
- No. The package works out of the box with zero configuration, and publishing config is optional for cases where you want to override defaults. There is no migration, no queue worker, no asset pipeline, and no artisan command required. Integration is effectively just the Composer require plus using the component tags.
- How do I change the size, color, or CSS class of an Elusive icon?
- Pass standard HTML attributes directly on the component, such as class, width, height, or style, and they are applied to the rendered SVG. For consistent sizing across a project, style them with your own CSS classes or utility framework instead of repeating attributes inline. The icons render as SVG, so color and size scale cleanly without pixelation.
- Can I use codeat3/blade-elusive-icons alongside other icon packages?
- Yes, but watch for namespace collisions. Several codeat3/blade-* icon packages follow the same naming pattern, and installing more than one set can produce duplicate component prefixes that shadow each other silently. That kind of conflict usually shows up as the wrong icon rendering rather than an error, so it can slip through code review. Validate your prefix uniqueness if you consume more than one icon package.
- Does the package add new icons over time or can I request custom glyphs?
- Elusive Icons is a frozen, static icon set, and this package is a delivery mechanism for it rather than a maintained design system. New or brand-specific glyphs are not something you can expect as a feature request. If you need an expanding icon library, plan for a different set or add your own custom SVG components alongside it.
- How do I handle accessibility for icons rendered by this package?
- The package renders the SVG markup, but accessible semantics are your template's responsibility. For decorative icons, add aria-hidden="true" so screen readers skip them. For icons that carry meaning, add a title or visually hidden text and ensure the surrounding control has an accessible name. Test with a screen reader as part of your normal QA, since the vendor cannot enforce these patterns for you.
- What are the alternatives to codeat3/blade-elusive-icons for Blade icons?
- If you only need the underlying infrastructure, blade-ui-kit/blade-icons lets you register your own SVG sets without a preset icon family. For other visual styles, packages exist for Heroicons, Font Awesome, Bootstrap Icons, and similar sets, several of them from the same codeat3 family. If you need tree-shaken, JS-driven icons or non-Laravel rendering, a front-end icon library is a better fit than a Blade component package.
- Is codeat3/blade-elusive-icons safe to use in production?
- For decorative UI work it is a low-risk dependency: it adds no database, queue, HTTP surface, or build tooling, and removing it later is a small, contained change. The main caveats are that it is single-maintainer and community-supported with no commercial SLA, and the icon set itself will not grow. Treat it as a cosmetic primitive rather than a platform component, and avoid depending on it for anything contractual or accessibility-critical without owning that risk internally.