garethp/http-playback
Record real HTTP responses once, then replay them deterministically in your PHP tests. GarethP's HTTP Playback makes it easy to capture and reuse external API interactions, keeping test suites fast, reliable, and free of network flakiness.
garethp/http-playback is a small, MIT-licensed PHP library aimed at recording HTTP interactions and replaying them, primarily useful for deterministic testing of code that talks to external services. It is architecturally a thin utility library: composer-installable, PSR-4 autoloaded, and designed to sit alongside an HTTP client (most likely Guzzle, based on the PHP HTTP ecosystem and the author's other packages). It is not framework-specific and carries no service provider or facade, so it does not need to hook into Laravel's container to function, though it can be wrapped for convenience.
Architecture fit. For a Laravel stack, fit is plausible but not native. Laravel's own Http::fake() and Http::record() primitives, plus mature VCR-style packages, already cover the record/replay use case with first-party documentation and active maintenance. Adopting this package means introducing a parallel testing utility with no Laravel integration and no community muscle memory, which is a net architectural minus unless it offers a specific capability the first-party options lack. v2.0 does not change this calculus — it closes a compatibility gap rather than opening a capability gap.
Integration feasibility. Technically low friction, and now materially lower than in the prior assessment: composer require garethp/http-playback, construct the playback client in test bootstrap, and point the application's HTTP client at it. The v2.0 Guzzle 7 upgrade is the significant change — Laravel's Http facade is built on Guzzle 7, so the package now speaks the same client major version as the framework. MIT licensing is clean for commercial use. Remaining friction is verification: "PHP 8.x" in the release note is a family-level claim, not a patch-level guarantee, and there is no stated Laravel version support matrix.
Technical risk. Downgraded from High to Medium, but not resolved. The two risks that dominated the prior assessment — PHP 8 incompatibility and a Guzzle 6-era client assumption — are both directly addressed by v2.0. That is a genuine, targeted fix rather than a cosmetic release. What remains unchanged: seven stars, zero dependents, a single maintainer, and one release after a multi-year gap. A single release is evidence of life, not evidence of a maintenance cadence. There is still no downstream validation, no issue-triage record, and no proven upgrade path against Laravel 10/11/12. The blast radius remains confined to CI reliability rather than production correctness, which keeps the downside bounded.
Key questions for the maintainer/sponsor.
Http::fake()/Http::record() or a maintained VCR alternative if this package is dropped?Stack fit. Composer-native and framework-agnostic, so it drops into a Laravel codebase without service provider changes. The practical placement is a test-only dependency (require-dev), wired into the HTTP client used by the application under test. It should never be a production dependency. With Guzzle 7 support, the package now sits on the same client major as Laravel's Http facade, which removes the adapter-shim work the prior assessment anticipated.
Migration path. Two directions matter. Inbound: from hand-rolled mocks or live-network tests to recorded fixtures — a contained, test-scoped change, now with a lower integration tax. Outbound: from this package to Laravel's first-party HTTP fake/record facilities or a maintained VCR-style library. Because recordings are just fixtures, the outbound path is mostly a format-translation exercise, which keeps lock-in low. That remains the strongest argument for a time-boxed evaluation rather than outright rejection.
Compatibility. Substantially improved and now the package's main selling point relative to its previous state. Guzzle 7 alignment with the Laravel HTTP client is the decisive compatibility win. The open items are narrower than before: verify the exact PHP 8 minor ceiling against our runtime (8.2/8.3 is not the same claim as 8.0), confirm PHPUnit version alignment, and confirm no Guzzle constraint ceiling that would block a future Laravel major. If composer.json pins an upper bound tight enough to block upcoming framework upgrades, fork ownership re-enters the cost model — but that is now a second-order concern rather than a likely blocker.
Sequencing.
composer.json constraints, the Guzzle 7 integration point, and the recording format — confirm whether v2.0 altered the fixture schema.Http::fake()/Http::record() and one maintained alternative.Maintenance. Still the dominant cost, but the forecast is better than previously assessed. v2.0 demonstrates the maintainer is willing to take a breaking-change release to stay current with PHP and Guzzle, which is the single most valuable maintenance signal for a test utility. What it does not demonstrate is repeatability — we have one data point after a multi-year quiet period. We should still assume we may own the code, but the probability-weighted cost of that ownership is lower. Budget for periodic compatibility patches and fixture-format stewardship; treat the v2.0 modernization as a reason to re-baseline the risk, not to remove the fork contingency.
Support. Unchanged and still weak. No meaningful community, no issue-response track record to rely on, and no ecosystem of users to consult. The v2.0 release note is a two-line changelog with no migration guide, no compatibility matrix, and no deprecation detail — which is itself a signal about the support posture we should expect. Internal documentation and a named maintainer remain prerequisites.
Scaling. As a test utility, runtime scaling is a non-issue; the scaling concern is fixture volume and drift. Large recorded corpora become stale as upstream APIs evolve, and re-recording requires network access and credentials in CI, which is exactly the toil record/replay is meant to remove. v2.0's potential fixture-format implications make this sharper: if the recording format changed, existing corpora may need regeneration, which is a one-time cost best measured during the spike. Plan a fixture-refresh policy and a way to detect stale recordings.
Failure modes.
Ramp-up. Low for engineers — the API surface is small and the concept is familiar to anyone who has used VCR-style tooling. The real ramp-up cost is organizational: establishing fixture conventions, ownership, and a refresh cadence. That cost is roughly the same regardless of which record/replay tool is chosen, which still erodes the case for a low-adoption package over a maintained alternative — though the gap has narrowed now that the package runs on the same Guzzle major as the framework.
Recommendation. Upgrade from "low-priority candidate" to "viable candidate, still not the default." v2.0 resolves the two blocking technical risks identified previously (PHP 8 support, Guzzle 7 alignment) and provides the first maintenance signal in years, which is sufficient to justify running the compatibility and comparative spikes rather than deferring them. Adoption should still be contingent on the spike demonstrating a concrete advantage over Laravel's first-party HTTP fake/record facilities or a maintained VCR alternative, and on written confirmation of the supported PHP minor range. If adopted, pin a commit, assign an internal owner, and budget for fork maintenance from day one — but re-evaluate that budget at the next upstream release rather than assuming permanent ownership.
How can I help you explore Laravel packages today?