Blade Health Icons Laravel Package

Product Decisions This Supports

• Icon strategy: build vs. buy vs. hand-rolled SVG. This package formalizes the Health Icons set as Blade components, so it decides "do we vendor a curated, health-domain icon library" rather than "do we maintain our own SVG sprite sheet." That's a build-vs-buy call with a low purchase price (a Composer dependency) and a real maintenance cost avoided.
• Healthcare/global-health domain fit. The Health Icons set is purpose-built for public-health, NGO, clinic, and humanitarian program interfaces — the iconography is semantically correct out of the box (vaccines, maternal care, water/sanitation, diagnostics), which reduces design and localization review cycles for those product lines.
• Framework-version roadmap. v6.0.0 is a compatibility-only major: it raises the Laravel/PHP floor to Laravel 13 and drops Laravel 11. This makes the package a line item in any Laravel upgrade plan — it cannot be adopted (or kept) on Laravel 11 past v5.x.
• Dependency-risk budgeting. Single-maintainer package with an infrequent release cadence. The decision it informs is not "should we use icons" but "how much do we allow a small third-party package to gate our framework upgrades."
• Use cases it unlocks: internal health-program dashboards, patient-facing service directories, field-data collection UIs, and any Laravel app where generic icon sets (Heroicons, Font Awesome) read as wrong for the audience.

When to Consider This Package

Adopt when:

• You are on Laravel 12 or 13 (and whatever PHP floor v6 requires — confirm on Packagist; the release notes say "PHP and Laravel compatibility" but do not state the PHP version) and want the Health Icons set rendered as first-class Blade components (<x-health-icon-... />) instead of raw SVG includes.
• The product's audience is health, humanitarian, or public-sector, where domain-specific iconography is a genuine UX differentiator rather than decoration.
• Your team is small and you would otherwise spend design/dev time sourcing, naming, and maintaining a consistent SVG set.

Look elsewhere when:

• You are pinned to Laravel 11 — v6 explicitly drops it. Stay on v5.x and accept that you are off the maintained head; re-evaluate at your next framework bump. Verify your composer.json constraint is ^5.0, not * or dev-main, or the drop is silent until runtime.
• You are not on Laravel Blade (Inertia/React/Vue-only front ends, Symfony, plain PHP). This package's value is the Blade component ergonomics; raw SVGs from healthicons.org travel anywhere.
• You need broad general-purpose icon coverage. This is a single-domain set, not a general icon framework — expect to run it alongside another library for generic UI chrome.
• You require strong maintenance guarantees: single maintainer, infrequent releases, no visible deprecation policy or a11y contract documented in the release notes. If icon accessibility attributes (aria-hidden, <title>, decorative vs. semantic) aren't exposed and tested, budget for a wrapper or a fork.
• You need a fully custom or branded icon set, RTL variants, or multi-color icons.

How to Pitch It (Stakeholders)

For executives: This is a small, free, open-source add-on that gives our Laravel health products a correct-looking, domain-appropriate icon set without design or licensing spend. The trade-off is maintenance risk: one maintainer, occasional releases. The v6.0.0 release adds no new icons — it is purely a compatibility bump that requires Laravel 13 and drops Laravel 11. Translation: it costs us nothing today, and it becomes a one-line item in our next framework upgrade. Do not treat it as a strategic dependency.

For engineering: v6.0.0 is a major version with a zero-delta feature set — the only breaking change is the removed Laravel 11 support and the raised PHP/Laravel ceiling. Pin explicitly (^6.0 on Laravel 13, ^5.0 on Laravel 11), confirm the new PHP minimum on Packagist before merging, and schedule the bump alongside — not ahead of — the framework upgrade so the two aren't decoupled in a rollback. Note the Laravel-compatibility PR came from a first-time contributor; review the diff for constraint accuracy rather than assuming it, and consider a thin internal wrapper around the components so a future abandonment or another major bump is a one-file change rather than a repo-wide find-and-replace.