Cloak Analyzer Laravel Package

Getting Started

cloak/cloak-analyzer is not a Laravel package — there is no service provider, no auto-discovery, and no publishable config. It is a framework-agnostic abstraction over code coverage tooling, so the first step is to confirm what it actually abstracts before writing any integration code.

composer require cloak/cloak-analyzer

Since the repository is archived and has zero dependents, treat the install as a spike rather than a commitment. Before adopting it, read in this order:

1. README.md — the only place the intended driver/adapter contract is likely documented.
2. src/ contracts — look for interfaces describing a coverage driver or report parser. These dictate how much of the package you can swap out later.
3. Existing implementations — any concrete classes shipped alongside the interfaces tell you which coverage format (Clover, Cobertura, PHPUnit XML) the package was actually built against.

First use case: take an existing PHPUnit Clover report and normalize it into a single object model you can gate on in CI, rather than parsing XML inline in a script. Generate the report with --coverage-clover=build/coverage.xml, then hand the file path to the analyzer and inspect the returned structure. If the analyzer only defines the abstraction without a working parser, you have your answer about viability immediately.

Implementation Patterns

Because the package provides abstractions rather than a Laravel integration, the day-to-day value comes from wrapping it yourself.

Bind the analyzer in a service provider. Register the concrete implementation behind the package's interface so tests can substitute a fake and so you can swap parsers without touching call sites:

$this->app->bind(CoverageAnalyzer::class, function () {
    return new XmlCoverageAnalyzer(config('coverage.report_path'));
});

Wrap it in an Artisan command. The most practical use is a coverage:report or coverage:gate command that reads the generated report, extracts per-file/per-class percentages, and exits non-zero when a threshold is missed. This keeps CI YAML thin and moves the logic somewhere testable.

Normalize at the boundary. Use the package's abstraction to convert whatever your driver emits (Xdebug or PCOV output, via phpunit/php-code-coverage) into a consistent shape. Downstream consumers — dashboards, PR comments, Slack notifications — should never see raw report XML.

Gate on delta, not absolute. Coverage abstractions typically expose per-file totals; the useful pattern is comparing current output against a cached baseline (store the previous JSON summary in the repo or artifact storage) and failing only on regressions. Absolute thresholds rot quickly.

Keep report generation and analysis separate. Let PHPUnit produce the artifact and let the analyzer consume it. Chaining them in one process makes flaky coverage drivers harder to isolate.

Gotchas and Tips

The package is archived. There will be no fixes for PHP 8.x deprecations, no support for Laravel 11/12, and no security maintenance. If it works, vendor it or fork it under your own namespace — do not leave a floating ^1.0 constraint resolving to an abandoned tree.

Zero stars and zero dependents means zero field validation. Assume the edge cases in report parsing (empty files, missing branches, anonymous classes, trait attribution) are untested against your codebase. Run it against a real project and diff the numbers against phpunit --coverage-text before trusting anything.

Coverage drivers are the real dependency. Xdebug is slow and memory-hungry on large suites; PCOV is faster but has narrower feature support. Neither is installed by default, and a "no coverage data" result often means the driver is missing rather than the analyzer being broken. Check php -m first when debugging empty output.

Debug by dumping the raw report. When numbers look wrong, cat the Clover XML and confirm the file paths and counts are what you expect. Path mismatches (absolute vs. relative, src/ prefixes) are the single most common cause of "0% coverage" in any coverage tooling.

Extension points are the only reason to use this. If the package ships interfaces for parsers or drivers, implement them rather than patching internals — that keeps your fork mergeable and makes migration to phpunit/php-code-coverage or a maintained alternative a one-class change.

Have an exit plan. phpunit/php-code-coverage is maintained, widely used, and exposes a Clover parser directly. For most teams the abstraction here saves little and costs the maintenance risk. Adopt only if the interface genuinely simplifies a multi-driver setup — otherwise parse Clover yourself in ~100 lines.