Packagegenerator Laravel Package

Product Decisions This Supports

• Build vs. buy on integration plumbing. For any partner that ships a WSDL (carriers, tax engines, ERPs, payment/treasury gateways, government/regulatory endpoints, legacy B2B), the choice is roughly: hand-write SOAP envelopes and XML parsing, use PHP's built-in runtime SoapClient, or generate a typed client package once and commit it. This package makes the third option cheap enough to be the default — which turns an open-ended R&D line item into a scoped, mechanical one.
• Roadmap sequencing and estimate confidence. Because effort scales with the WSDL and not with the number of hand-written mappers, you can plan "one enterprise partner per sprint" with far tighter error bars, and commit delivery dates to commercial teams earlier.
• Architecture standardization. Generated DTOs give you a natural anti-corruption layer: third-party SOAP types stay at the boundary, your domain models stay clean. That's a decision you can make once and reuse across every SOAP integration instead of relitigating per project.
• Contract-as-dependency governance. Output is a standalone, versionable PHP package. That lets you tag a partner contract (acme-api 2.4.0), diff regenerated output in code review when the partner publishes a new WSDL, and roll back — a real release-management decision, not just a codegen convenience.
• Runtime dependency decisions. Generated code does not require ext-soap and does not fetch/parse the WSDL per request. That removes a hosting constraint (shared hosting, slim containers, locked-down PHP builds) and a latency/failure mode (partner WSDL endpoint down = your app down).
• Vendor negotiation leverage. When you can absorb a contract revision in an afternoon, you can accept partner-driven schema changes rather than push back on timelines — and conversely, you can push back when the WSDL is genuinely broken, because you'll know quickly.
• Migration and sunset planning. Generated classes are the honest inventory of what a legacy SOAP dependency actually does. That is the input for deciding whether to wrap-and-hide, keep, or replace each partner over the next 12–24 months.
• Staffing and bus factor. Typed classes with IDE autocomplete and static-analysis support mean ordinary PHP developers can do the integration, rather than one SOAP/XML specialist being a single point of failure.
• Feature scoping. "Which operations do we actually call?" becomes a concrete list in the generated service class — useful for negotiating rate limits, SLAs, and sandbox access with the partner.

When to Consider This Package

Adopt when:

• The integration is genuinely SOAP/WSDL and the WSDL is reasonably complete and current — this is the hard prerequisite, and it is less often true than vendors claim.
• You're on PHP/Laravel and want the partner contract represented as typed classes your team (and PHPStan/Psalm/IDE) can reason about.
• The contract is stable enough to version but likely to change a few times a year — regeneration-and-diff is exactly the right workflow.
• You want to avoid ext-soap at runtime, either for hosting reasons or because per-request WSDL parsing is slow or fragile.
• You'll do more than one SOAP integration. The setup cost (install, config, CI regeneration step, review discipline) amortizes; one is a judgment call.
• You need the generated code to live in your repo under your license and release process — MIT, generated output is yours, no vendor lock-in.
• You care about auditability: an engineer can read the generated class for an operation instead of decoding an XML dump from a failed call.

Look elsewhere when:

• The partner offers REST/JSON or GraphQL — regenerate nothing, just use an HTTP client. Don't let SOAP momentum decide this.
• The service uses WS-Security, SAML assertions, MTOM/attachments, WCF-specific behaviors, or heavy custom SOAP headers. These are the known rough edges of code generation generally; budget for hand-written signing/header logic layered on top, or route through a middleware/gateway in a stack that handles it well.
• The WSDL is broken, incomplete, or unavailable — common with older enterprise vendors. Generated code inherits every schema defect; you'll spend more time fighting the generator than writing the client.
• It's a one-off, low-value call where PHP's SoapClient in runtime mode is two hours of work and this is two days of setup plus CI.
• The team won't own the generated code — if nobody reviews regeneration diffs, you get silent behavior changes on a partner's schedule.
• You're not on PHP, or you're mid-migration off PHP and don't want new PHP surface area.
• You need fully dynamic behavior — arbitrary operations selected at runtime from user input — where a generic runtime client fits better than compiled classes.
• Health check: 434 stars is a niche, real, but small community, and effectively zero recorded dependents. Treat it as maintained-by-a-small-team open source: verify it supports your PHP version, vendor it, pin it, and have a plan to fork or replace. The active recent release cadence is reassuring; the bus factor is the risk to record in your register.

How to Pitch It (Stakeholders)

For executives (one paragraph): Enterprise and B2B partners — carriers, tax and payment providers, ERP and regulatory systems — still expose SOAP/WSDL interfaces. Today each one is a bespoke, hard-to-estimate engineering project with a specialist dependency. This tool turns a published WSDL into a typed PHP client package automatically, so onboarding a partner becomes a repeatable, forecastable workflow rather than a research project. It's MIT-licensed with no runtime or per-seat cost, the generated code belongs to us, and it removes a hosting constraint and a live dependency on the partner's servers. The trade-off is modest: a small setup and review process, and a real limitation around advanced security/attachment features that some partners require. Net: shorter time-to-first-successful-call per partner, lower maintenance cost, and less key-person risk in a part of the codebase that is otherwise opaque.

For engineering (the pitch and the caveats):

• It's a CLI generator, not a runtime library. Point it at a WSDL + XSDs, get a Composer package: typed DTOs for every schema type plus a service class with one method per operation. Vendor it, tag it, review it.
• No ext-soap needed at runtime, no per-request WSDL fetch. Faster and more resilient than SoapClient in WSDL mode, and it's statically analyzable.
• Workflow: add a script (composer gen:acme-api), run it when the partner publishes a new contract version, and let the diff be the review artifact. Never hand-edit generated files — extend or decorate them instead.
• Where it will hurt: WS-Security/SAML signing, MTOM attachments, exotic headers, and genuinely broken WSDLs. Scope those explicitly before committing a date; assume some hand-written transport logic on top.
• Ask before you commit: pin the generator version, confirm PHP version support, and note in the risk register that it's a small-maintenance open-source project — we should be comfortable forking or replacing it.