- How do I install codeat3/blade-govicons in a Laravel app?
- Install it with a single Composer command, typically composer require codeat3/blade-govicons. Laravel package auto-discovery registers the service provider, so there is no publish step, migration, config file, or npm install. After that you can reference icons directly in any Blade view. If you already have blade-ui-kit/blade-icons in your lockfile, keep an eye on the version constraint during resolution.
- What Blade syntax do I use to render a GovIcon?
- Icons render as Blade components using the x-govicon-* tag, for example <x-govicon-name />. The prefix is govicon-, so verify it by listing the package's SVG directory before you build templates around a name. Because Blade renders unknown tags verbatim rather than throwing, an incorrect prefix or icon name produces empty output with no error or log entry.
- How do I change the size, color, or CSS classes of a govicon?
- Pass standard HTML attributes and classes to the component tag, such as class="size-6 text-blue-600" or explicit width and height attributes. The package is designed to work with utility-class styling like Tailwind, but any CSS setup works. Be aware the package ships no default sizing, and hardcoded fill values in some SVGs can break currentColor inheritance, so confirm the output renders the color you expect.
- Which Laravel versions does codeat3/blade-govicons support?
- The real compatibility gate is the blade-ui-kit/blade-icons constraint, not the illuminate/support version, so check that dependency against your existing lockfile before assuming an issue. If blade-icons is already installed at a compatible version, adoption is essentially one Composer line. The package itself is a thin view-layer wrapper, so it has little else to conflict with.
- Is there a config file or assets to publish after installing?
- No. There is no publish step, no configuration file, no migration, and no frontend asset pipeline to run. The service provider simply registers the bundled SVG assets with blade-icons as Blade components. That makes the install effectively a Composer line plus a component-prefix check.
- Why is my govicon rendering as blank or nothing at all?
- The most common cause is an unknown icon name or the wrong component prefix, because Blade outputs unrecognized tags verbatim and logs nothing. Confirm the prefix, which is govicon-, and list the vendor SVG directory to get the real icon inventory. Also check that the blade-icons dependency resolved and that your styling is not hiding the SVG through size or color rules.
- Does codeat3/blade-govicons work with Inertia, React, or Vue front ends?
- No, and it is not meant to. The package only makes sense in server-rendered Laravel Blade views, where the component tag does the work. In an Inertia, React, or Vue front end you would consume the same MIT-licensed SVGs directly as assets, and the Blade wrapper adds nothing. If your UI is JavaScript-driven, skip this package.
- Can I use it alongside other icon sets like Heroicons or Font Awesome?
- Yes, in practice it is designed as part of the codeat3/blade-icons family and registers components with blade-ui-kit/blade-icons, so multiple icon packages can coexist under their own prefixes. Just confirm that the shared blade-icons constraint in your lockfile satisfies every icon package you install. A two-tier policy of civic icons versus a general set is usually the cleanest approach, documented so teams know which set to reach for.
- What are the maintenance and production risks of this package?
- This is a thin presentation dependency with a small footprint: no runtime service, no database, no queue, and no outbound HTTP, so the blast radius is low. The confidence risk is moderate because it has a single maintainer, few stars and dependents, and a release history mostly made of framework-compatibility bumps. It is acceptable because the assets are MIT and the wrapper is trivially forkable, so the worst case is inlining the SVGs into an application-owned directory.
- How do I find the available icon names, and how should I test them?
- Read the package's SVG directory end to end; that listing is both your inventory and your confirmation of the component prefix. Map it against real UI needs, and if only a handful of names are relevant the dependency probably is not earned. For testing, render each icon you actually use in a Blade view and assert the output contains the expected SVG markup, which catches typos and prefix mistakes that would otherwise fail silently.