Badger Laravel Package

Product Decisions This Supports

• Build vs. buy for status/health badges: Badger renders SVG badges (build status, version, coverage, custom metrics) server-side in PHP, so you can add badges to READMEs, status pages, or customer-facing dashboards without a Node toolchain or a third-party shields.io dependency in your request path.
• Roadmap and platform-upgrade planning: v5.0.0 supports Laravel 12 and 13 and requires PHP 8.2+. This is the gating signal for whether the package can ride along on your next framework upgrade — if your platform is still on Laravel 8–10, you are pinned to the 4.x branch and that constraint belongs in your upgrade plan.
• Feature decisions on visual consistency: The new for-the-badge style (modeled on shields.io) lets you match the badge aesthetic teams already expect from GitHub READMEs. If brand or docs consistency matters, this closes a gap that previously forced a shields.io workaround or custom SVG work.
• Use cases worth validating with design/eng: status page indicators (Cachet-style), release/version badges, coverage or SLA badges in internal docs, and dynamically generated badges driven by your own app data (queue depth, incident count) where a hosted third-party badge would leak or depend on external uptime.
• Maintenance/risk posture: The jump from 3.x to 5.x plus automated tagging, release publishing, and changelog generation is evidence of an active, low-ceremony release process — a positive vendor-health signal, but the version leap also means you should audit for changes you skipped (there is no 4.x line note beyond the legacy branch).

When to Consider This Package

Adopt when:

• You need server-rendered SVG badges from PHP/Laravel and want to avoid adding a JS/Node service or calling shields.io at runtime.
• Your stack is PHP 8.2+ and Laravel 11/12/13 — v5.0.0 is aligned with current framework releases.
• Badges are generated from your own data (status, metrics, versions) where an external badge service is undesirable for privacy, reliability, or latency reasons.
• You want shields.io-compatible styling, including the new for-the-badge variant, so badges look native in GitHub and internal docs.
• You value a package that ships with Pest-tested compatibility across framework versions and PHP 8.4-safe signatures.

Look elsewhere or defer when:

• You are on Laravel 8–10 or PHP < 8.2 — you would need the 4.x branch, which you should treat as maintenance-only and unsupported for new work.
• You need rich badge catalogs, icon sets, or hosted badge endpoints — Badger renders what you tell it; a hosted service or a broader SVG library may fit better.
• Badges are purely static marketing assets — committing pre-rendered SVGs is cheaper than a runtime dependency.
• You require a formal support/LTS commitment or security policy — this is a small, single-maintainer-style package; verify bus factor before making it load-bearing on a customer-facing surface.
• You need client-side/dynamic badge rendering or non-PHP services in the mix.

Adoption checklist for this release: confirm PHP 8.2+ and Laravel 12/13 in CI, pin to ^5.0, explicitly test any custom badge templates against the new style system, and scan for any removed APIs between 3.x and 5.0.0 since intermediate releases were skipped.

How to Pitch It (Stakeholders)

For executives (one line): Badger is a small, actively maintained PHP package that generates shields.io-style SVG badges directly from our Laravel app — no external badge service, no extra infrastructure, and it now supports our current Laravel and PHP versions.

For engineering: v5.0.0 adds Laravel 12/13 support, a shields.io-compatible for-the-badge style, and automated tag-driven releases; it requires PHP 8.2+ and drops Laravel 8–10 (4.x branch remains for legacy apps). The upgrade is a version bump plus a quick audit for skipped 4.x changes — the package is Pest-tested and PHP 8.4-safe. Recommend pinning ^5.0, adding it to the framework-upgrade checklist, and avoiding it on any surface where a single-maintainer dependency is unacceptable.