Wsdl2Php Generator Cli Laravel Package

Product Decisions This Supports

• Build vs. buy for legacy/SOAP integrations. Most SOAP work in a Laravel codebase isn't a product feature — it's a partner or enterprise requirement (ERP, payments, logistics, telecom, government portals). This package lets you decide "scaffold and own the generated classes" instead of "build a bespoke client layer by hand," and gives you a defensible time estimate for either path.
• Roadmap sizing for integration work. Generating typed request/response classes from a WSDL turns a multi-day ticket ("write 60 DTOs and a client by hand") into an hours-long one. That directly affects how many partner integrations you can commit to in a quarter, and whether a one-off integration is worth doing at all.
• Scope decisions on third-party contracts. Because the generated output is plain PHP you own, this supports the decision to not couple your domain layer to the SOAP endpoint — you can generate, then hand-edit or wrap the output behind your own interface. That's a "buy the boilerplate, own the boundary" decision.
• Feasibility spikes. Before committing to a partner, run the generator against their WSDL. If it produces clean, usable classes, the integration is low-risk. If it chokes (imports, xsd:any, non-standard schemas), you learn that in an hour and can reprice the roadmap item — cheap discovery, no architecture commitment.
• Tooling vs. product investment. This is a dev-time accelerator, not a runtime dependency. That means you can adopt it under a "developer tooling" budget line without a production risk review, and drop it without a migration.
• Do not use it to justify building a general-purpose SOAP platform. It's a scaffolder. If you find yourself wanting it at runtime (dynamic WSDLs, per-tenant endpoints), that's a separate, bigger build decision.

When to Consider This Package

Adopt when:

• You have one or more concrete WSDLs to integrate and the schema is reasonably standard (named complex types, no heavy imports or xsd:any).
• Your team is already on PHP/Laravel and you want generated classes that drop into your existing namespace, autoloading, and IDE/static-analysis setup.
• You want a CLI, run-once, commit-the-output workflow — generation happens at development time, and the generated code is reviewed like any other code.
• The integration is time-boxed and narrow (a handful of operations), where hand-writing DTOs is pure overhead.
• You're willing to vendor or fork the tool and pin it in require-dev. The signal here is thin — 4 stars, 0 dependents, a single maintainer, and it is a thin console wrapper over the wsdl2phpgenerator library.

Look elsewhere (or skip generation) when:

• You can depend on the underlying library directly. This package is a convenience wrapper; if you need it in CI or want control, calling Wsdl2PhpGenerator from a small Artisan command of your own is ~50 lines and removes a link from your supply chain.
• The WSDL is non-trivial. Multiple wsdl:import, inline schemas, anyType, choice groups, or WS-Security/WS-Addressing requirements will likely produce output you'll fight. Budget for hand-written mapping instead.
• You need a maintained, supported dependency. With 0 dependents and a low activity signal, treat it as sample code, not a vendor-supported tool. If your org requires an SLA or security review of dev dependencies, this won't clear the bar.
• You need modern HTTP. The output typically assumes ext-soap / SoapClient. If your platform standard is PSR-18/PSR-17, async, or you need mocks and contract tests, generate the types but plan to build your own transport layer.
• You need runtime flexibility. Per-customer endpoints, versioned WSDLs served at runtime, or dynamic operation selection are not what a code generator gives you.
• REST/OpenAPI is the actual need. Don't reach for a SOAP generator because it's the closest thing in the PHP ecosystem; use an OpenAPI generator.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed developer tool that turns a WSDL contract into ready-to-use PHP classes, cutting the mechanical work out of partner/SOAP integrations. It carries no runtime dependency and no licensing cost, so the downside is limited to engineering hours on a spike. The upside is that we can quote integration timelines based on a one-hour feasibility test rather than guesswork. Caveat to state plainly: the project is small and lightly maintained, so we'd treat it as internal tooling we control (pinned, optionally forked), not a supported third-party product.

To engineering: Use it as a scaffolder, not a dependency of the application. Run the CLI against the WSDL, review the generated classes, commit them, and wrap them behind your own client interface so the SOAP surface stays at the edge of the codebase. Expect to hand-fix edge cases in complex schemas. Because adoption is require-dev-only and the output is plain PHP, the exit cost is near zero — if the tool is abandoned, we keep the generated code and, if needed, reimplement the ~50-line generation step against the underlying library. Recommend a timeboxed spike per integration: one hour to validate the WSDL generates cleanly, then a go/no-go.