Blade Zondicons Laravel Package

Product Decisions This Supports

• Feature delivery speed on Laravel Blade surfaces. This package turns the Zondicons SVG set into ready-to-use Blade components (<x-zondicon-home class="w-5 h-5" />), so dashboards, admin panels, settings screens, CRUD views, empty states, and internal tools ship without hand-managed SVG files or a bespoke icon pipeline. It is a sprint-capacity lever, not a differentiator — measure it in days of design/engineering effort saved per surface, not in user-facing novelty.

• Build vs. buy vs. borrow. The realistic alternatives are (a) hand-maintaining SVG assets in the repo, (b) adopting blade-ui-kit/blade-icons with a broader multi-set strategy, or (c) pulling in a JavaScript icon library. This package is the borrow option: near-zero build cost, near-zero switching cost, because it is presentation-only and namespaced. That low coupling is the point — it is a low-regret, trivially reversible decision that does not need a design-system committee to approve.

• Roadmap and platform-upgrade planning. Release 1.7.0 is a compatibility-only release (Laravel 13 support, PR #239): no new icons, no config keys, no API changes, no deprecations. The product decision it unblocks is keeping the Laravel 13 upgrade path open — without the widened constraint, Composer refuses to install alongside illuminate/* ^13.0, turning a routine framework bump into a forced icon-layer migration. Slot it into the upgrade plan as a dependency bump, not a workstream.

• Icon strategy — declare up front that Zondicons is a frozen set. The set is effectively static upstream and the package will not gain artwork. That is a strength for a stable, opinionated visual language and a liability if design or product expects to request new glyphs. Make the call now: "our icon vocabulary is fixed unless we add a second set." Surfacing that constraint before adoption is far cheaper than discovering it mid-quarter. (Note also a documentation discrepancy worth resolving before anyone writes a number into a spec: the description advertises "220+ icons" while reference material cites ~290 glyphs — confirm from the tagged package.)

• Multi-set consolidation as a single decision. Apps commonly land on two or three codeat3 icon packages (Heroicons, Eva Icons, Zondicons). They share the blade-icons runtime, so one naming convention, one <x-icon> wrapper, and one deploy-time cache command cover all of them. Decide "which icon sets do we standardize on" once, not per package.

• Deployment and performance hygiene. php artisan icons:cache pre-registers icons into a manifest and is the single biggest win on icon-dense pages (tables, nav lists, paginated cards). A small, one-time platform ask that pays off on every icon-bearing surface.

• Dependency risk management. 48 stars, 0 dependents, community-maintained. The correct posture is tactical: pin the version, scope a Dependabot/Renovate rule to it so Laravel-major compatibility releases surface automatically, and verify licence and constraint metadata from the tagged composer.json rather than from changelog prose.

• Explicitly out of scope: custom brand icons, icon uploads, sprite governance, SVG optimization pipelines, multi-family search over one registry, enterprise support or SLAs. If any of those land on the roadmap, this package is background context, not the answer.

When to Consider This Package

Adopt when:

• The product is a Laravel application rendering Blade templates — a hard prerequisite, not a preference. Non-Laravel PHP services should consume raw SVGs directly.
• You need a small-to-moderate, opinionated icon set for internal tools, admin surfaces, MVPs, or early-stage products where consistency and ship speed outweigh a bespoke icon system.
• You want server-rendered inline SVG with no JavaScript dependency — good for SSR, good for accessibility control (aria-* passthrough), good for Tailwind sizing (class="w-5 h-5").
• You are planning or executing a Laravel 13 upgrade and need dependencies whose constraints permit it.
• You value fast implementation and low maintenance over customized icon workflows. Ramp-up is under an hour for a developer comfortable with Blade components.
• You already use, or plan to use, blade-ui-kit/blade-icons — this package is additive to that runtime, not a competing mechanism.

Look elsewhere when:

• You need multiple icon families under managed governance, custom icon uploads, or a full design-system icon platform. blade-icons with several sets — or an in-house registry — fits better than a single frozen set.
• The frontend is primarily React, Vue, or another SPA framework — a JavaScript icon package is the natural fit.
• You require enterprise support, SLAs, or vendor-backed maintenance. This is a community package with a small footprint; the genuine risk is upstream abandonment of the design set, not package breakage, and the blast radius of a defect is a mis-rendered icon.
• You need sprite generation, tree-shaking, advanced SVG optimization, or automated icon governance. Note the scaling caveat: inlining many SVGs inflates HTML payload on icon-dense pages and multiplies markup inside loops, so sprite-sheeting or <use> references may eventually be warranted. Not a blocker at typical scale, but out of scope here.
• The Zondicons visual style does not match the product brand — a design call to make before, not after, adoption.
• Licence or long-term maintenance requirements cannot be satisfied by a community-maintained MIT package.

Verification gates before committing (hours, not weeks):

1. Confirm PHP and illuminate/support constraints from the tagged composer.json in CI, not from the one-line changelog; check the runtime PHP meets the Laravel 13 floor.
2. Land the dependency bump alone on a low-traffic branch and confirm the container boots and views compile — this catches provider-registration and auto-discovery issues for near-zero cost.
3. Validate component name collisions against any in-house <x-zondicon-*> components, and confirm the config supports prefixing if collisions exist.
4. Adopt on one surface first (e.g. an internal admin area) to prove attribute passthrough (class, width/height, aria-*) and a11y behaviour.
5. Confirm a fallback path if the maintainer stops shipping compatibility releases: fork, or vendor the SVGs directly. Both are viable precisely because the package is presentation-only.
6. Confirm the licence/attribution expectation if SVGs are inlined into shipped bundles.

How to Pitch It (Stakeholders)

For executives — one paragraph, low-stakes framing: This is a small, MIT-licensed Laravel package that gives our product a consistent, professional icon set with minimal engineering effort — no custom SVG work, no JavaScript dependency, no design-system build-out. The 1.7.0 release is a compatibility-only update adding Laravel 13 support: a low-risk maintenance event that keeps our framework upgrade path open. It is a tactical UI dependency, not a strategic platform bet, and should be treated like any community package — pinned, monitored, and replaceable in under a day. There is no licensing cost and no operational surface: no config to sync, no scheduled tasks, no external service. I am not asking for a budget line or a roadmap slot, only permission to spend roughly a day of engineering adopting it on internal surfaces, plus a small recurring dependency-hygiene cost.

For engineering — practical and specific: blade-zondicons exposes the Zondicons set as <x-zondicon-*> Blade components via blade-ui-kit/blade-icons. Composer install plus auto-discovery yields working components with no config publishing and no service-provider registration. 1.7.0 widens constraints for Laravel 13 (PR #239) with no breaking changes, no deprecations, no migration steps; the 1.6.0 → 1.7.0 delta is additive, so there is no pressure to move frameworks to consume it. Recommended adoption shape: (1) verify constraints from the tagged composer.json in CI; (2) land the bump alone and boot-smoke-test view compilation; (3) wrap usage in a single <x-icon> component so sizing and colour changes are not a repo-wide find-and-replace, and use @svg()/svg() for DB-driven names — with validation on any user-influenced name; (4) add php artisan icons:clear && php artisan icons:cache to the deploy script; (5) roll out to one internal surface before customer-facing views, with a visual diff in the PR; (6) scope a Dependabot/Renovate rule to this package. Failure modes worth noting in the PR: component name collision (surfaces at view compile), constraint mismatch after a framework upgrade (provider fails to register — caught by the boot smoke test), and silent icon removal on a future release, which renders empty rather than erroring — mitigate with a visual regression check on icon-bearing views. Budget under an hour of ramp-up; the real effort is design-system alignment (sizing conventions, stroke widths, a11y labelling), which is a frontend/design pairing, not platform work. No operational runbook is warranted beyond the dependency-update note.

For product — what to do with it and what to expect: Use this to ship consistent UI faster on dashboards, admin panels, and internal tools. Raw <x-zondicon-*> calls scattered across views make every sizing or colour change a repository-wide edit, so route them through one wrapper component from day one — that is a design-system decision, not an engineering detail. Set expectations early with design that Zondicons is a fixed content set: new icon requests will require a different library or hand-authored SVGs, and that conversation is much cheaper now than mid-quarter. It is a tactical UI dependency, not a differentiator — revisit only if we need custom brand icons, multi-set icon management, or stricter support and licensing guarantees. If we standardize on multiple icon sets later, consolidate that decision once and keep the same naming and wrapper convention across all of them.