Phpunit Coverage Listener Laravel Package

Product Decisions This Supports

• Coverage telemetry: build vs. buy. This package is a working precedent for the "push coverage results to a remote endpoint from CI" pattern that Codecov, Coveralls, SonarQube, and GitLab Coverage Visualization productized. It is useful as prior art when deciding whether to build an internal coverage ingestion service or buy a SaaS/self-hosted equivalent.
• Whether to invest in an internal coverage dashboard. If your org already has a metrics/observability backend, this shows the ingestion contract can be thin — a listener that serializes PHPUnit coverage and POSTs it. That lowers the estimated build cost of an in-house uploader and may shift the roadmap toward "integrate, don't buy" for a narrow internal use case.
• CI/CD roadmap and legacy support tiers. The package's dependence on the PHPUnit listener API (removed/changed in modern PHPUnit) is a concrete data point for planning end-of-life for legacy PHP 5.x builds and for budgeting migration to native coverage formats (--coverage-clover, --coverage-cobertura).
• Reference architecture for telemetry clients. Useful for defining payload shape, push-vs-pull, and where coverage collection belongs (test runner vs. separate CI step) — not as a dependency.
• Use cases it validates: monolithic legacy PHP apps on PHPUnit 3.x/4.x with a self-hosted, air-gapped metrics endpoint; ad-hoc "coverage per commit" tracking before a vendor tool existed.
• Signal caution: the high opportunity score reflects whitespace in coverage telemetry broadly, not the viability of this package. Do not let a scoring artifact drive an adoption decision.

When to Consider This Package

Consider only when all of the following hold:

• You are maintaining a legacy PHP 5.x codebase pinned to PHPUnit 3.x/4.x where the listener API still exists.
• You own the receiving endpoint and can accept the package's fixed payload schema without changes.
• You have a hard constraint against third-party coverage SaaS (air-gapped, data residency, procurement freeze) and no internal uploader exists yet.
• You need this for a short, time-boxed migration window, are willing to vendor/fork the single listener class, and accept best-effort delivery.
• You have reviewed the cURL code path yourself for TLS/auth behavior, since no one else will.

Look elsewhere when:

• You are on PHPUnit 9/10/11 — the listener extension point is gone; use native Clover/Cobertura output plus a maintained uploader (Codecov, Coveralls, Sonar, GitLab).
• You need authentication, retries, idempotency, TLS verification, or merging of sharded/parallel coverage — none of that is productized here.
• You require maintenance, security patching, or community support: archived since 2013, zero dependents, no releases in over a decade.
• Compliance or security review applies — unmaintained network code is a finding waiting to happen.
• You need branch/path normalization or PR-level diff coverage.

How to Pitch It (Stakeholders)

Executives: Do not adopt. This is an archived 2013 utility with 49 stars, zero dependents, and no releases or security patching for over a decade. Its only real value is as evidence of how coverage reporting can be wired up: it proves the integration surface is small. Recommendation is to keep the current native-coverage-plus-uploader path (or a bought tool) and treat this as a reference, not a dependency. Cost of ownership — security review, forking, PHPUnit-version lock-in — exceeds any savings.

Engineering: The idea is one listener that serializes PHPUnit coverage and cURLs it to an endpoint. If we want internal coverage ingestion, we can implement that contract ourselves in days against current PHPUnit and control auth, retries, and payload versioning — rather than inheriting an unmaintained fork that won't run on modern PHPUnit. Use it to sanity-check our payload design, then build the thin client we actually own.