Blade Govicons Laravel Package

Product Decisions This Supports

Build vs. buy for civic iconography. GovIcons is a purpose-built set of government and public-service symbols, and this package wraps the full set as MIT-licensed Blade components. For a govtech, civic-tech, or public-sector Laravel product, that replaces a "commission or hand-draw a domain icon set" line item with a one-line Composer require. The PM decision collapses to a single question: is domain-specific iconography on the roadmap at all? If yes, adopting here is an order of magnitude cheaper than building, and the alternative isn't "build it better" — it's "ship generic icons that read as wrong to agency users."

Concrete use cases that justify the dependency. Agency identifiers in directory tables and nav, service-category badges on a benefits or permitting catalog, icons on multi-step regulatory workflows, status indicators in admin queues. These are exactly the surfaces where a generic chevron-and-heart set forces semantic drift — using a "settings" gear for "permits" — and where the drift is hardest to unwind once it's in ten templates.

Keeping the Laravel 13 upgrade off the critical path. Release 1.6.0 is a narrow illuminate/support compatibility bump, which is precisely the signal a roadmap needs: this dependency will not become an upgrade blocker, so the platform migration doesn't need a "replace abandoned icon package" workstream carved out of it. Treat it as a check to repeat at each framework major, not a durable guarantee — the release history is one compatibility bump, not a track record.

Committing to a two-tier icon strategy — deliberately. This is a vertical set, not a general one. It enables an explicit architectural decision worth writing down: GovIcons for civic semantics (agencies, services, public infrastructure, benefits and regulatory flows), a general set (Heroicons, Lucide) for utility UI (chevrons, search, close, menu). Making that call now is the decision; the failure mode is letting it emerge by accident as four or five icon libraries accumulate with no owner and no one able to explain why the same chevron looks different in two places.

Frontend toolchain scope. Icons ship as Blade components with inline SVG — no npm step, no JS bundle, no external CDN calls. For server-rendered apps, internal admin panels, and legacy Blade codebases without a frontend pipeline, this closes the icon question without opening a build-tooling workstream. That's sprint capacity that stays with feature work.

Reversibility classification as a process asset. The package is a thin wrapper: SVG assets plus a service provider that auto-registers components. Cheap to adopt, cheap to fork, cheap to remove — the worst case is a few hours inlining assets into our own resources/svg directory behind an existing wrapper component. That justifies routing it through a lightweight "low-consequence, reversible" approval lane rather than formal vendor review. Deciding that tier once gives you a reusable path for every leaf dependency that follows.

Where not to spend design capacity. Because the set is narrow, the same evaluation tells you what to deprioritize: don't staff a design-system icon audit against a dependency that renders a handful of civic glyphs, and don't budget brand-governance or vendor-management time against it.

When to Consider This Package

Adopt when:

• You're building a government, civic, or public-service product on Laravel/Blade where agency and service iconography is part of the information architecture, not decoration.
• You want icons as Blade components with no build-pipeline coupling — server-rendered apps, internal tools, teams without a frontend toolchain.
• You're planning or executing a Laravel 13 upgrade and want one fewer dependency that could block it. Confirm the constraint window in composer.json rather than the changelog; on Laravel 10–12, verify 1.6.0 hasn't narrowed support before standardizing, otherwise pin 1.5.0 and fold the bump into the framework upgrade.
• You want MIT-licensed, forkable assets with no vendor relationship, contract, or licensing review.
• Adoption cost is genuinely near zero: one Composer line, auto-discovery, no required config publishing, no migration, no npm install. Five minutes of verification covers it — confirm the component prefix (it's either govicon- or govicons-, and the wrong one renders silently empty rather than erroring), read the asset listing end to end as your icon inventory, and check the blade-ui-kit/blade-icons constraint against your lockfile, since that's the realistic resolution conflict rather than Laravel itself.

Look elsewhere when:

• Fewer than a handful of the icons map to real UI needs. Read the shipped inventory first; if the set doesn't cover your surfaces, the dependency isn't worth carrying.
• Your frontend is a JS SPA or Vue/React/Inertia app consuming an npm icon package — the Blade wrapper adds nothing there.
• Iconography is brand-critical or under design governance, with a need for bespoke, trademark-sensitive, or officially sanctioned government marks. This set is community-maintained and generic-purpose; it is not an official seal library.
• You need a broad general-purpose set — this is a vertical, and stretching it into utility glyphs is the abuse case.
• Anyone proposes building core UI abstractions on top of it. Two stars, zero dependents, and a release history of one compatibility bump qualifies as a leaf asset dependency and nothing more. The mitigation remains forkability, not vendor diligence.

How to Pitch It (Stakeholders)

To executives: We have a domain-specific iconography gap in our civic-facing surfaces, and the choice is between commissioning a set and adding a small MIT-licensed open-source package. The package is a one-line install, costs nothing, requires no contract or vendor relationship, and carries no build-tooling or runtime overhead. It's genuinely reversible — the assets are open and the wrapper is thin, so the downside case is a few hours of internal work, not a migration. Recommendation: approve it as a leaf dependency under our lightweight review lane, and note the decision to use this set for civic semantics and a general set for utility UI so we don't accumulate libraries by accident.

To engineering: One composer require, auto-discovery, no publish step, no npm. Every icon is a Blade component styled by currentColor, so text-* utilities handle color and dark mode. Three things to get right up front: verify the component prefix against the actual asset listing (a wrong prefix fails silently — Blade emits the unknown tag verbatim into the DOM), wrap it in an app-level <x-ui.icon> component on day one so sizing, aria-hidden, and a future library swap are a single-file change, and add php artisan icons:cache to the deploy script with icons:clear on rollback to avoid a stale registry across web nodes. Watch the blade-icons constraint, not the Laravel one, when resolving. Standardize first on one high-traffic civic surface — a nav item, a service badge, an agency cell in a table — and let code review propagate the pattern.

Explicit caveats to state up front: the set is narrow and should stay that way; icon-only buttons need aria-label on the control rather than aria-hidden on the SVG; icons need explicit sizing since there's no default; and the Laravel 13 support should be re-verified at each framework major rather than assumed. If a needed civic glyph is missing, add an SVG to our own registered icon path rather than forking the package — that keeps the upstream update path open behind the same component call site.