Nusoap Bundle Laravel Package

Product Decisions This Supports

• The "should we ship SOAP at all?" call. This bundle does not decide whether your product supports SOAP — it only decides how the runtime gets wired into a Symfony2 container. Any PM decision that treats it as the answer to "we need SOAP" is mis-scoped. The real decision it informs is runtime selection, not feature scoping.
• Build vs. buy vs. borrow. Adopting this is "borrow with a fork." The savings are roughly a day of DI and config wiring; the cost is inheriting NuSOAP's unmaintained, PHP 5-era surface area on your roadmap with no patch channel. For a PM, that trade is almost never favorable against ext-soap, which ships with PHP and is maintained by php-src.
• Legacy integration triage. Best signal value is as a marker: WSDL/SOAP endpoints tied to B2B/EDI partners, government filing APIs, telecom or tax gateways, and legacy ERP are exactly where this pattern shows up. Use it to find and budget those integrations for migration, not to cement them.
• Where it earns a narrow, time-boxed place: an existing Symfony 2.x application already speaking NuSOAP that needs container-managed clients, non-WSDL mode, client-side WSDL caching, SwA attachments, or custom type serialization that ext-soap handles poorly.
• Where the PM should explicitly not greenlight it: any new product surface, any Laravel application, any greenfield service. With 0 stars, 0 dependents, and a score of 0, there is no adoption evidence to cite in a build/buy review. The question shifts from "does it work?" to "who owns it when it breaks?"

When to Consider This Package

Consider it, narrowly, when:

• The application is genuinely Symfony 2.x and will stay there — the bundle class, service definitions, and config tree are Symfony2-era and do not port forward cleanly.
• You have an existing NuSOAP codebase and want clients wired through the container instead of scattered new nusoap_client(...) calls.
• You need NuSOAP-specific behavior ext-soap does not provide — non-WSDL mode, WSDL caching, SwA attachments, or a partner's idiosyncratic serialization.
• The integration is internal, low-volume, non-regulated, and you can commit to vendoring, pinning, and naming an owner.

Look elsewhere when:

• The application is on Laravel — this is a Symfony2 bundle; there is no ServiceProvider, no facade, no auto-discovery. composer require yields an inert dependency, and the Symfony 2.x constraint will almost certainly conflict with the Symfony 6/7 components Laravel 10/11 pull transitively. Use ext-soap, a maintained NuSOAP fork, or an integration platform instead.
• The application is on Symfony 3/4/5/6/7 — reimplementing ~100 lines of service wiring is cheaper than dragging this bundle forward.
• The work is greenfield — prefer symfony/soap, laminas-soap, or WSDL-generated clients with an active CVE path.
• You are in PCI/HIPAA/regulated scope — NuSOAP is unmaintained; XML external-entity handling and TLS defaults are dated with no patch channel.
• You are on PHP 8.x — expect deprecation noise and possible breakage from PHP 5-era constructs.
• You need vendor support, an SLA, or CVE response — zero stars and zero dependents means no community bench, no maintainer depth, no Stack Overflow coverage.

How to Pitch It (Stakeholders)

Executives: This is a small Symfony integration shim around NuSOAP, a legacy PHP SOAP toolkit. It is not a strategic dependency: no community, no active maintainers, no security response. Recommend it only as a time-boxed tactical bridge for legacy B2B SOAP endpoints while migration to a supported SOAP client is funded. Frame the ask as "legacy lifeline with an exit plan and a named owner," not "new dependency." The headline number for the room: 0 stars, 0 dependents, 0 score — we would be the last consumer.

Engineering: Treat this as vendored code. What it buys is DI and configuration for NuSOAP under Symfony2, nothing more. If the application is on Laravel or Symfony ≥3, do not adopt the bundle — reimplement the wiring, or skip it entirely and go native. Budget 1–2 days to vendor, validate against the target WSDL, and add contract tests around each SOAP operation so partner schema drift surfaces as a test failure rather than a production incident. Isolate every call behind a SoapGatewayInterface bound in a service provider/config so the eventual exit to ext-soap is a one-line binding change, and push all outbound calls onto queues so a dead counterparty cannot exhaust web workers.

Risk register entry: abandoned upstream + EOL framework + no security patch path = acceptable only with an explicit migration ticket, a sunset date, and a named owner.