Product Decisions This Supports
- Health-check / liveness endpoint design. The package remains a "ping" bundle — the surface consumed by load balancers, uptime monitors, Kubernetes probes, and APM tooling. Its value to a PM is as a reference contract (path, status codes, response body, auth expectations), not as an implementation to adopt.
- Build vs. buy (still favors build). v4.0 does not change the fundamentals: the supplier risk is a single maintainer with effectively no adoption signal, no support path, and no CVE-response process. The correct decision remains to specify the endpoint internally and implement in-house.
- Framework fit in the platform roadmap — unchanged and decisive. The
-bundle suffix and moveis-simonetti vendor confirm a Symfony bundle, not a Laravel package. For a Laravel-centric roadmap this is a non-starter on framework grounds regardless of release cadence.
- Maintenance-liveness signal (revised). v4.0 is the first release since the Jan 2024 v3.1 — the project is not abandoned, but its activity is event-driven (a framework-compatibility bump), not steady-state. Treat "occasionally revived" as a distinct risk category from "dead": it means the package will likely keep working on new framework majors, but you inherit the upgrade cadence of someone else's hobby project.
- Upgrade-cost modeling for pinned dependencies. The v3.1 → v4.0 major bump ("update 6 & 7") is the textbook example of why low-activity packages are a maintenance tax: a major version number for what is very likely a framework-version support change, arriving with no migration guide and a non-descriptive changelog.
- Dependency-minimization policy. A useful data point for third-party surface-area arguments: MIT is fine, but each dependency carries upgrade, security-review, and license-attribution overhead. Here the overhead is disproportionate to ~20–50 lines of functionality.
When to Consider This Package
Consider it only when all of the following hold:
- The stack is Symfony 6.x or 7.x (v4.0 appears to target these; verify against
composer.json before anything else, since the release notes do not say so explicitly).
- You want a ready-made ping route and are willing to accept a zero-adoption, single-maintainer dependency for roughly 20–50 lines of equivalent code.
- You have a documented process for pinning low-activity packages and accepting the long-term maintenance burden, including major-version upgrades you did not schedule.
Look elsewhere — or build in-house — when any of these are true:
- You are on Laravel. Framework mismatch is unchanged and remains the primary disqualifier. Laravel's built-in health route or a two-line closure covers the need.
- You are on Symfony 5.x or earlier. The v4.0 major bump very likely drops older framework support; confirm the supported range and the migration path before assuming this is a drop-in upgrade.
- Health checks are production-critical. Liveness/readiness endpoints gate traffic. A package with no dependents and a single maintainer is not a defensible dependency on a traffic-gating path — new framework support does not create a support relationship.
- You need meaningful semantics. Real health checks answer "are my dependencies reachable?" — database, cache, queue. A bare ping says only that PHP booted.
- Security or compliance review is required. Continued near-zero adoption means continued near-zero external scrutiny; expect to read every line yourself.
- You need SLAs, CVE response, or a support contact. None exist here.
How to Pitch It (Stakeholders)
For executives: We re-reviewed this package following its v4.0 release. The release is a framework-compatibility update (Symfony 6 and 7 support) and a major version bump — it tells us the maintainer is still active, but it does not change the adoption picture: no dependent projects, no support relationship, no security-response process, and it targets Symfony rather than our Laravel stack. Recommendation stands: do not adopt. The functionality is a handful of lines we can own outright, and the dependency adds a maintenance and review obligation with no offsetting benefit.
For engineering: v4.0 is almost certainly just a platform bump — Symfony 6/7 support — shipped as a breaking major with no migration notes, so treat it as a compatibility signal, not a feature. The cost of writing the endpoint ourselves is under an hour and gives us full control over the response contract, dependency checks (DB, cache, queue), auth, and logging. Pulling it in buys us nothing but a transitive dependency whose upgrade schedule we don't control. If we want a standard, define it internally and reuse it across services.
Bottom line: The package is alive again but still low strategic value, negligible adoption, and the wrong framework for us. Treat it as prior art for a health-check spec, not as a candidate dependency. The only material change since the last review is that "unmaintained" should be restated as "sporadically maintained" — which slightly improves the odds it works on new framework majors and does nothing to improve the case for adopting it.