Compiling multiple wdsl files into a single client

[rieger-jared]

We have a couple of wdsl files and right now we're building each into a separate client. Is there a way to compile multiple wsdl into the one client?

[sergeliatko]

Short answer: the generator is intentionally single-WSDL, and in most cases composing separate generated clients is the better long-term choice than merging. But "which WSDLs, and why combine them" changes the recommendation, so let me lay out the paths.

Quick diagnostic

A few questions, with the path each answer points to:

1. Are the WSDLs from the same vendor / same logical service (just split across files), or independent services?
2. Do any of them share type or operation names (e.g. two of them define a User, or both have a GetStatus operation)?
3. What's the goal? Single npm install for consumers / single HTTP surface / shared auth / one deployable / all of the above?
4. Do the upstream services version in lockstep, or can one ship a breaking change without the other?

Path A — Same upstream, split across WSDLs

If the WSDLs are really one logical service whose schema is split (common with vendors that modularise xsds), the right fix is upstream, not in the CLI. Author a top-level WSDL that xs:imports the others and point --wsdl-source at that. The loader already follows xs:import / xs:include transitively, and the compiler resolves cross-namespace references. This gives you a single client with zero changes to the generator.

Path B — Independent services, you just want one install / one HTTP surface

This is the most common case, and composition at the app layer handles it cleanly. Generate one client per WSDL (what you're doing now) and wire them together:

// services.ts
import { ClientA } from "./generated/service-a/client/index.js";
import { ClientB } from "./generated/service-b/client/index.js";

export const services = {
a: new ClientA({ source: process.env.WSDL_A! }),
b: new ClientB({ source: process.env.WSDL_B! }),
};

If you also want a single HTTP surface, mount both generated Fastify gateways under different prefixes in one app:

await app.register(gatewayA, { prefix: "/services/a" });
await app.register(gatewayB, { prefix: "/services/b" });

Keeps independent regeneration, independent versioning, failure isolation per service, and avoids every collision problem.

Path C — You want a unified public API (one package, one typed entry point)

Wrap the generated clients in a small facade package that re-exports them under namespaces:

// index.ts
export * as A from "./generated/service-a/client/types.js";
export * as B from "./generated/service-b/client/types.js";
export { ClientA } from "./generated/service-a/client/index.js";
export { ClientB } from "./generated/service-b/client/index.js";

Consumers write A.User vs B.User and get full type safety with no collisions. You own the facade, so breaking changes in one upstream don't ripple into the other's types.

Path D — You genuinely need one merged client (not recommended)

Worth being explicit about why the generator doesn't do this today:

• Types, aliases, and operations in the compiled catalog are keyed by local name only. Two WSDLs with a User or GetStatus would silently
  overwrite or merge — no error surfaced.
• The generated client class takes a single source URL in its constructor and routes every method through it. There's no per-operation endpoint selection.
• The OpenAPI spec and the generated Fastify gateway are 1:1 with a WSDL.

Making the generator do this properly means namespace-prefixing every generated identifier (ServiceA_User, ServiceB_User), teaching the client to pick endpoints per operation, and emitting an OpenAPI doc with per-operation servers. The resulting code is strictly less ergonomic than Path C for consumers, and it couples the services' release cycles. I'd only pursue this if you're locked into a single endpoint for transport reasons (e.g. one gateway in front of both) and the WSDLs are guaranteed not to collide — and even then, a thin wrapper is almost always simpler.

Recommendation

If you tell me which of the four situations matches yours (and whether there are name overlaps), I can sketch the concrete wiring. My prior is that most people asking this question are in Path B or C, and the answer is "keep the separate clients, add a small composition layer." Path A only if the WSDLs belong together upstream, Path D almost never.