Blade Health Icons Laravel Package

Technical Evaluation

What this release is. v6.0.0 is a platform-matrix release, not a feature release. The diff is two PRs: raise PHP/Laravel compatibility (Laravel 13 support added) and drop Laravel 11. There are no reported changes to component names, the icon set, the registration mechanism, or published assets. The major version bump is a convention signal — this package appears to treat support-matrix changes as breaking, which is defensible (a hard drop of Laravel 11 genuinely breaks installs) but means routine framework upgrades will always land as majors here.

Architecture fit. Excellent for this package's class. It is a pure view-layer dependency: SVGs shipped as Blade anonymous components, registered via a service provider (auto-discovered), no routes, no migrations, no config surface of consequence, no persistence, no runtime services. It does not touch the domain layer, cannot influence data integrity, and adds no middleware or boot-time work beyond component namespace registration. From a TPM standpoint that makes it a "leaf" dependency: cheap to adopt, cheap to remove, and it should never appear on an architecture risk register for anything other than supply chain and upgrade cadence.

Integration feasibility. composer require troccoli/blade-health-icons and use <x-health-icon-* />. Effort is measured in minutes, not sprints. The only real constraint is the Composer solve: the package now requires a newer Laravel and PHP floor, so adoption is gated on the host application's platform version, not on any integration work.

Technical risk. Low at runtime, moderate at the process level:

• Coupling to the framework upgrade treadmill. Because support windows are enforced with major bumps, this package will force a Composer constraint decision on every Laravel major. That is a predictable, recurring cost — small, but it must be scheduled rather than discovered during an unrelated upgrade.
• Dropping Laravel 11 while it may still be inside its security-support window is the one genuinely contentious call. Applications deliberately holding on L11 for security-patch-only stability cannot take v6 and will stop receiving fixes (including any icon-set or rendering fixes) on the v5 line. Confirm whether v5 receives security-level maintenance; if not, L11 apps are on an unsupported branch.
• Blast radius if it breaks is cosmetic only — an icon fails to render — never a 500 in a transactional path unless a component is called inside an unguarded view with strict exception handling. That is a strong risk profile.
• Supply chain / bus factor. Single-maintainer project with a first-time contributor in this release. Low-value target, but also low redundancy. Pinning and lockfile discipline is the mitigation.

Key questions.

1. What are the exact PHP floor and the full supported Laravel range in composer.json for v6? "Update PHP and Laravel compatibility to v.13" is ambiguous between "PHP 8.3+/Laravel 12–13" and "PHP 8.4/Laravel 13 only."
2. Is Laravel 12 still supported in v6, or only 13? This determines whether the upgrade is a lateral move or a forced platform jump.
3. Does v6 change any icon slug, component name, or the published-views path? The notes say no, but the notes also omit the manifest.
4. Is v5 being kept open for security/patch fixes, and for how long?
5. Is the icon set itself re-synced from upstream Health Icons in this release? If so, visual regressions are possible even with no API change.
6. Does the package publish assets, and does v6 alter the publish tag or destination?

Integration Approach

Stack fit. Native fit for any Laravel 12/13 application using Blade. It also works in Livewire, Inertia (server-rendered Blade partials), and mail templates, since it is just component rendering. It is not appropriate for API-only services, non-Laravel PHP, or front-ends that consume icons from a CDN or design-system package — in those cases, treat it as out of scope rather than forcing it in.

Migration path. There is no code migration. The work is:

1. Verify the host app's PHP and Laravel versions satisfy v6's constraints before touching the constraint.
2. Bump troccoli/blade-health-icons to ^6.0 in composer.json and run a full composer update in a branch, committing the lockfile.
3. Diff the resolved vendor tree — this package should pull nothing transitive, so any new package in the lockfile diff is a red flag.
4. Render-smoke-test the views that use the icons (a route crawl or a Blade compile pass plus a visual diff of one representative page is sufficient).
5. Run php artisan view:clear and re-warm caches in every environment, including any precompiled-view artifact in the deploy pipeline.

Compatibility. The hard boundary is the Laravel 11 exclusion. Any application, package, or long-lived maintenance branch still on L11 must remain pinned to ^5.0 and be explicitly recorded as such — an unpinned composer require in CI will otherwise silently downgrade or fail. Because other first-party and third-party packages may have their own L11 windows, sequence the framework upgrade ahead of this bump and let this package ride along in the same PR as the framework version change rather than as a standalone dependency PR.

Sequencing. Recommended order: (a) inventory every place an icon component is referenced, so the smoke-test surface is known; (b) confirm the platform target and any sibling packages that also gate on the Laravel major; (c) upgrade the framework; (d) bump this package in the same change set; (e) run the render smoke test; (f) update the platform-support table in internal docs. If the framework upgrade is not funded this quarter, take the explicit decision to stay on ^5.0 and log the support-window expiry date — do not leave the constraint floating.

Operational Impact

Maintenance. Near-zero steady-state cost: no configuration to drift, no migrations to run, no scheduled jobs, no runtime services to monitor. The recurring cost is entirely the upgrade cadence described above — one dependency-bump ticket per Laravel major, plus whatever v5-to-v6 gap exists for teams deferring. Budget it as a recurring line item, not a one-off.

Support. No vendor SLA. Upstream support is GitHub issues and community PRs from a single maintainer. For an icon package this is acceptable; the mitigation is version pinning plus a documented exit path — the icons are static SVGs, so worst case the used icons can be copied into resources/views/components and the dependency dropped with a mechanical find-and-replace. Confirm that fallback is viable before adopting, and record it.

Scaling. Irrelevant in the horizontal sense — rendering is a Blade component include with no I/O, no external calls, and no cache dependency. Two second-order concerns: repository size, since the icon set ships in vendor/ and inflates every deploy artifact and container layer; and view-cache/opcache footprint if the full set is compiled. Neither is a reason to avoid the package, but if deploy artifact size is a constraint, verify whether the package supports publishing only a subset of icons rather than the full set.

Failure modes. Ranked by likelihood:

1. Component not found at render — a mistyped or renamed icon slug surfaces as a Blade component resolution error. Usually cosmetic in a layout, but a hard failure if raised inside a mail or PDF render path. Mitigation: a view-level smoke test covering icon-bearing templates.
2. Composer solve failure or unintended downgrade — the L11 drop causes a constraint conflict during an unrelated upgrade, or a floating constraint pulls v6 into an L11 app and breaks the build. Mitigation: explicit constraints everywhere, lockfile committed.
3. Stale compiled views after upgrade — old compiled component paths persisting post-deploy. Mitigation: always clear and re-warm view cache as a deploy step.
4. Visual regression from an upstream icon-set re-sync — silently different glyphs after a bump. Mitigation: a single visual snapshot on a page that uses several icons.
5. Abandonment — the maintainer stops shipping. Low severity given the static-asset exit path, but it should be a reviewed decision each major cycle, not an assumption.

Ramp-up. Effectively none. A developer who knows Blade needs no documentation beyond the icon name list; there is no package-specific mental model to acquire. The only onboarding item worth writing down is the pinning policy and the L11 exclusion, so the next person to run composer update does not have to rediscover it.