- How do I install codeat3/blade-ant-design-icons in a Laravel app?
- Run composer require codeat3/blade-ant-design-icons. The package is auto-discovered, so there is no service provider to register and no publish step before use. You can drop an icon component into a Blade view immediately after Composer finishes.
- Which Laravel versions does blade-ant-design-icons support?
- The package tracks Laravel majors, and version 1.10.0 is specifically a Laravel 13 compatibility release with no feature or API changes. Because the illuminate/support constraint and the icon inventory ship as one version unit, treat package adoption and framework upgrades as the same planning event. Run composer why-not against your actual lockfile to see whether the constraint is a widening or a PHP/Laravel floor raise before committing.
- What is the correct Blade component tag syntax for an Ant Design icon?
- The shipped convention is a flattened tag such as <x-antdesign-home />, where the icon name is appended to the antdesign prefix. Note that the package description still advertises the older <x-ant-design-icon name="home" /> form, which is a real documentation discrepancy. Verify the exact tag against the installed package's views directory rather than trusting the README.
- How do I change the size, color, or CSS classes of an icon?
- Attributes pass through to the rendered SVG element, so size, color, class, and other standard HTML attributes work as you would expect. For example, <x-antdesign-home size="32" color="#0ea5e9" class="mr-2" /> renders a styled inline icon. You can then target it further with Tailwind or your own stylesheet.
- Do I need to publish config or assets after installing?
- No. The package is a presentation-layer-only dependency that registers Blade components and introduces no configuration surface, migrations, middleware, or asset pipeline changes. That also makes removal cheap: a composer remove plus a find-and-replace sweep of the icon tags is enough to unwind it.
- Does this package require JavaScript, a CSS file, or a CDN?
- No. Icons render as inline SVG directly in your Blade output, so there is no JS runtime, no stylesheet to load, no CDN request, and no build-tool configuration on the PHP side. The trade-off is that inline SVG increases HTML payload, which is negligible on admin screens but worth measuring on icon-dense public pages.
- How do I find the right icon name or component tag for a glyph?
- There is no runtime name lookup, so mapping a desired glyph to its tag is an information problem rather than an engineering one. Browse the icon index on ant.design for the glyph you want, then check the installed package's views directory for the exact flattened tag. Most names translate predictably to antdesign-plus-name, but confirm before shipping.
- Will this package slow down my app or break view:cache in production?
- Components are anonymous and resolved lazily, so per-request startup cost is negligible. However, a full icon set is hundreds to thousands of view files, so measure the view:cache artifact size and CI cold-build delta against your pre-adoption baseline instead of assuming. If either number matters to you, render only the icons you actually use.
- What are the alternatives to blade-ant-design-icons?
- The closest alternatives are sibling Blade icon packages such as blade-heroicons, blade-tabler-icons, and blade-fontawesome, which use the same component-per-icon pattern with different icon sets. If you only need a handful of glyphs, inlining SVG or using an SVG sprite may be simpler than adding any dependency. Pick based on whether you specifically need Ant Design's visual language.
- Is codeat3/blade-ant-design-icons safe and well maintained for production use?
- It is a single-maintainer package with essentially no external dependents, so on any framework bump you are plausibly the canary exercising the upgrade path first. Engineering risk is low because the package only influences emitted HTML and is removable with composer remove, but risk concentrates in scheduling and governance. It is a reasonable choice for internal and back-office surfaces, and should be a documented, deliberate decision before customer-facing critical paths.