Blade Grommet Icons Laravel Package

Product Decisions This Supports

• Build vs. buy for design primitives. The alternative to this package is not "no icons" — it is someone internal owning an SVG component library: curating files, wiring a service provider, handling naming, reviewing PRs. codeat3/blade-grommet-icons collapses that into one Composer line. The decision to make explicitly is whether icon delivery is core IP (build) or commodity plumbing (buy). For most products it is plumbing, and the buy side wins on cost alone — but decide it once, in writing, so the org does not end up with three icon systems running in parallel.
• Design-system standardization as an enforceable policy. Moving to <x-grommet-icon name="add" /> turns "please use the design system icons" from a style-guide request into something a reviewer can see in a diff. That is the actual product value: consistency that survives code review and staff turnover, not the SVGs themselves.
• Roadmap: clearing the Laravel 13 upgrade line. Release 1.11.0 is a compatibility bump, not a feature. Its planning value is that it removes this dependency as a candidate blocker from the framework migration. Log it as a cleared checkbox and move on; do not let it become a work item.
• Scope discipline / anti-roadmap. This package should consume approximately zero roadmap attention: a dependency review, a version pin, an occasional bump. If "icon system initiative" appears on a roadmap, that is a signal the team is over-investing in a commodity — unless the product is itself a design tool.
• Use cases it unlocks cheaply: server-rendered admin panels, internal tooling, dashboards, customer portals, marketing pages, and transactional email — anywhere inline SVG rendered from Blade is the right answer, with no JS bundler, no icon-font payload, and no client runtime. Also relevant where CSP or offline/email rendering makes icon fonts a liability.
• Ownership decision that actually matters. Zero GitHub stars and zero dependents mean nobody else is stress-testing this for you. The PM decision is therefore not "adopt or not" but "do we consume this as a dependency, or do we treat the SVG set as an asset we effectively own and could vendor in half a day?" Choose deliberately; the answer determines how much process you wrap around it.
• Documentation as a deliverable. The most common failure mode is drift into a mixed inventory where nobody knows which icon set is canonical. Budget for a published icon catalogue — names, rendered previews, sizing scale, colour-inheritance rule, and the decorative-vs-meaningful accessibility convention — plus a named owner. That artefact, not the package, is what makes the adoption stick.

When to Consider This Package

Adopt when:

• The surface is a Laravel app rendering Blade — standard views, Livewire, Filament, Inertia with Blade roots, or Mailables. API-only services and headless SPA front ends get nothing here.
• You want icons with no frontend build step: no npm, no sprite pipeline, no icon-font download, SSR-friendly inline SVG.
• Grommet's vocabulary matches your design spec. Grommet is a focused, enterprise/dashboard-leaning set. Validate coverage name-by-name against the real designs before committing — discovering a gap mid-migration is the expensive version of this decision.
• You are planning a Laravel 13 upgrade and want one fewer name on the blocker list.
• You value cheap reversibility: removal is one Composer line plus a set of tags, and the escape hatch (vendor the SVGs, keep the registration provider) is a half-day job.

Look elsewhere when:

• You need a broad or expressive library, brand/social glyphs, or a steady stream of new icons. Heroicons, Tabler Icons, Lucide, and Font Awesome are materially larger and have comparable Blade wrappers in the same blade-ui-kit ecosystem.
• Your design system is already codified in Figma, a token-driven component package, or a custom SVG pipeline. A second icon vocabulary produces drift, not consistency.
• You need icons at runtime on the client — dynamic props, animation, bundler tree-shaking. Use a JS icon library.
• You require formal support, an LTS commitment, a security policy, or a vendor SLA. This is a single-maintainer community package with no external dependents. Fine for cosmetic output; not fine for anything load-bearing.
• Icons would become the sole affordance in a critical flow. Keep the blast radius cosmetic — a missing icon must degrade to a blank glyph, never to a broken checkout.
• Upstream licensing or attribution obligations for the Grommet set conflict with your distribution model, including white-labelled or client-delivered builds. Confirm before shipping.
• The team already standardizes on another blade-ui-kit set. Switching then buys a rename, not a capability — unless Grommet's vocabulary is specifically what the design calls for.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated a small open-source Laravel package that exposes the Grommet icon set as reusable Blade components. Its latest release, 1.11.0, is compatibility-only — it adds Laravel 13 support — which is a maintenance signal, not a new capability. The business case is modest and low-risk: it removes a small amount of repeated hand-written SVG work, makes icon usage consistent and reviewable in code, and, most relevant to planning, it will not stand in the way of a future Laravel 13 upgrade. Cost is effectively zero and the dependency footprint is tiny. Recommendation: a low-stakes, reversible adoption only where the Grommet vocabulary already matches our designs. This is not a strategic investment, and it is the wrong choice if we need a broad icon library or a formally supported vendor dependency. Note the package has essentially no external adoption — zero stars, zero dependents — so plan to treat the icon set as something we could vendor ourselves rather than something a community will maintain on our behalf.

To engineering: 1.11.0 adds Laravel 13 compatibility with no breaking changes, deprecations, or new features — the upgrade from 1.10.0 is a routine bump. Treat the package as an icon-delivery utility: Blade components rendering inline SVG, no JS, no build-pipeline coupling, SSR-safe, suitable for email and static rendering. Before adopting, confirm three things: (1) icon coverage against the design spec, (2) upstream Grommet licence and attribution obligations, and (3) whether a broader set (Heroicons / Tabler / Lucide) better matches conventions we already have. Then run the standard playbook: pin ^1.11 and commit the lockfile rather than floating; prove with composer why-not laravel/framework 13.* that the package's blade-icons / illuminate/support constraints don't become the upgrade blocker; wire the blade-icons cache step into deploy with write access at build time and a read-only runtime filesystem; and add a CI check that renders every icon component referenced in templates so an upstream rename surfaces in CI rather than in a customer's browser. Keep the dependency at a leaf of the graph so it stays trivially replaceable, and if it ever becomes load-bearing, mitigate by vendoring the SVG source rather than forking the package. Net action: a standard dependency review plus a note in the Laravel 13 checklist that this dependency is already cleared.