Soap Recorder Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy — resolved decisively toward build. This package is archived, explicitly [DEPRECATED], has 12 stars, 0 dependents, and no maintainer. There is nothing to buy and nothing to depend on. The decision it informs is how to source SOAP record/replay for our test suite: reference the MIT-licensed design, or implement a thin in-house equivalent (roughly 200–400 LOC) behind an interface we own. Either way, we own the outcome.
• Roadmap sequencing for legacy integration coverage. If the product still leans on SOAP endpoints — payments, ERP, government or healthcare gateways — this raises a real planning question: how much test-double infrastructure do we fund for integrations we intend to retire? The correct output is a scoped spike ("deterministic SOAP fixture replay in N days?"), not a dependency addition. This package validates the problem while failing the sourcing test.
• Platform standardisation and framework fit. This is a Symfony bundle, not a Laravel package — no service provider, no package discovery, no Laravel config. Adopting it in a Laravel-first estate means importing Symfony bundle conventions and a second DI idiom for exactly one testing concern. That mismatch is itself a decision input, and the answer is almost certainly no.
• A standing policy on test-infrastructure risk. Record/replay tooling sits directly on the correctness of our CI signal. Archived, unmaintained code in that position means silent breakage on PHP/runtime upgrades with no patching path. This supports a durable rule: test-infrastructure dependencies must be actively maintained or vendored in-repo.
• Use-case validation. The unmet need is genuine — capture real SOAP traffic once, replay it deterministically in CI, and eliminate slow, flaky, network-bound integration tests. The package proves the pattern is worth solving, and gives us a concrete reference for the record-once/replay-thereafter model.
• Fixture hygiene as a first-class product concern. SOAP headers routinely carry credentials, tokens, and PII, and this tool writes them to committed YAML by default. That elevates redaction policy, fixture review, and secret scanning from an engineering detail to a decision we must make before the first recorded run.

When to Consider This Package

Effectively never for new work. The narrow, defensible conditions are:

• You are already on a legacy Symfony 2/3 codebase with this bundle in composer.json, and the live question is migration and removal sequencing rather than adoption.
• You need a reference implementation for SoapClient interception and fixture serialisation, and you intend to fork or vendor under MIT with an explicit, resourced maintenance commitment.
• You are doing archaeology on an inherited test suite to understand why fixtures look the way they do.

Look elsewhere — or build — when:

• You are on Laravel. Framework mismatch alone disqualifies it. Treat SOAP as XML-over-HTTP and use HTTP-layer record/replay (Http::fake() fixture patterns, or php-vcr) instead.
• You need maintained code, PHP 8.x compatibility, ext-soap currency, or any security responsiveness.
• Your SOAP interactions require WS-Security, MTOM/attachments, or strict WSDL versioning — the scope here is thin, unmaintained, and unlikely to cover fault-versus-success replay or typed SOAP objects.
• Contract-first fixtures would do the job: hand-authored or generated SOAP response XML checked into the repo and replayed through a test HTTP client. For most teams this is the cheaper, more durable answer, and it removes the secret-capture problem almost entirely.

How to Pitch It (Stakeholders)

Executives: Do not adopt. The library is officially deprecated and archived, with no maintainers, no dependents, and a framework that does not match our stack. It does point at a real problem — our SOAP integration tests are slow and flaky — but the fix is a small, owned piece of test infrastructure rather than a third-party dependency. Expect one to two days of engineering, no licensing cost, and no ongoing vendor risk. The MIT licence lets us read the original code; we simply accept that anything we borrow, we maintain.

Engineering: We are declining liip/soap-recorder-bundle. It is a Symfony bundle with no Laravel service provider or package discovery, it is archived and untouched since deprecation, and it would gate our CI signal on code nobody maintains — an unjustifiable trade for a test-only utility. The pattern is still right: intercept SOAP calls at the client boundary in test mode, record XML request/response pairs as fixtures keyed by a hash of method plus normalised arguments, and replay deterministically offline. We propose a short spike to (a) confirm whether the SOAP traffic is HTTP-observable, in which case php-vcr or an HTTP fake gets us there with better framework fit, or (b) implement a RecordingSoapClient decorator behind an interface we control, with record / replay / passthrough modes and production bindings untouched. Two non-negotiables before the first recorded run: a redaction policy for headers and payloads, and replay-only enforcement in CI so a cache miss can never silently reach a live endpoint. The MIT licence lets us reference the original's SOAP envelope handling directly, with the clear understanding that we own whatever we copy.