- How do I install andreiio/blade-iconoir in a Laravel app?
- Run composer require andreiio/blade-iconoir. Laravel package auto-discovery registers the service provider, so the Blade components are available immediately with no build step, no JavaScript runtime, and no CSS import. Optionally run php artisan vendor:publish to get the config file for default attributes. Realistic effort for a first integration is well under a day, including a small styling and QA pass.
- Which Laravel and PHP versions does blade-iconoir support?
- Because the package is a thin Blade asset wrapper, its constraints follow Laravel's Blade component system rather than any heavy dependency stack. Still, confirm the exact Laravel and PHP ranges declared in composer.json on the Packagist page before committing, since those constraints are the authoritative answer and change between releases. Check that the release you pick tracks your current Laravel major; a wrapper this small is usually quick to upgrade or fork if it lags.
- How do I use an Iconoir icon in a Blade template?
- Render an icon with the component tag matching the icon name, for example <x-iconoir-activity />. Component names derive from upstream Iconoir identifiers, so the tag is generally the kebab-case form of the icon name. The component outputs inline SVG, which means it inherits currentColor and can be styled with ordinary CSS or Tailwind classes. Because it is pure Blade, it behaves the same in plain Blade views, Livewire components, and Inertia page templates.
- Can I set a default size, stroke width, or CSS class for all icons?
- Yes. The package ships an optional publishable config file that lets you define default attributes such as class, size, and stroke width. Publish it with php artisan vendor:publish and edit the defaults once instead of repeating attributes on every tag. You can still override any default per icon by passing attributes directly on the component tag.
- Does blade-iconoir work with php artisan view:cache in production?
- The package renders through standard Blade components, so it should be compatible with compiled views, but whether components are registered lazily or eagerly enumerated at boot is worth verifying for your version. Run a full view:cache and view:clear cycle in staging as part of the deploy pipeline, then render a page containing several icons to confirm nothing breaks once the cache is warm. Treat that check as a standard acceptance criterion rather than an assumption.
- What breaks when I upgrade blade-iconoir and the bundled Iconoir version?
- The main risk is icon-name drift: a component is generated per upstream icon identifier, so if Iconoir renames or removes an icon, the affected tag fails at render time with a Blade unable-to-locate-class-or-view error rather than at composer install or compile time. That failure mode is not signalled by semver, and patch releases have carried real icon payload changes; the 4.7.1 bump to Iconoir v7.11.1 is an example. Pin the version, read the changelog to see which icons were added versus changed, and smoke test your icon-heavy screens before deploying.
- Does blade-iconoir add runtime dependencies, database tables, or external HTTP calls?
- No. It is an asset-only package: it ships the Iconoir SVG set and registers Blade components, plus an optional config file. There is no database, queue, cache dependency, outbound HTTP call, or request-time service provider work beyond component registration. That makes it safe to adopt in codebases with strict runtime-dependency policies.
- What is the performance cost of inlining Iconoir SVG icons in Blade?
- Each component inlines an SVG, so icon-heavy pages produce larger HTML documents; that is a front-end payload concern to include in your acceptance criteria rather than a defect in the package. There is also a registration cost, since one component per icon can mean a large view or classmap depending on the implementation, which only matters for apps rendering many distinct icons per page or running on a very tight boot budget. Measure your own pages before optimising, and consider a sprite or cached-view approach if the numbers justify it.
- How do I migrate from hardcoded inline SVGs or a Heroicons Blade package to blade-iconoir?
- Replace SVG partial includes or other icon component tags with <x-iconoir-... /> tags one surface at a time. From inline SVG partials the change is mostly attribute-driven, meaning size and stroke, so expect a styling pass; from another package such as a Heroicons wrapper it is a mechanical find-and-replace plus a visual regression pass, because tag names and icon vocabularies differ. Iconoir is a stroke-based 24px outline set, so if your design system uses filled or duotone icons, budget for visual-parity work. Because changes are template-level and additive, migrations can be incremental and rolled back per view.
- Who maintains blade-iconoir and what happens if it is abandoned?
- It is a single-maintainer open-source package, and much of the visible repository activity is automated dependency pull requests, so bus factor is a genuine consideration. The mitigation is that it is a static asset wrapper with no runtime coupling: you can fork it, or vendor the SVG set and generate your own components, in very little time. If governance matters to you, compare other Blade icon wrappers such as Heroicons- or Tabler-based packages, but weigh the migration cost against the small risk here.