@techspokes/typescript-wsdl-client 0.24.0 → 0.26.0

package/docs/roadmap/v1.0-wsdl-coverage-matrix.md

@@ -0,0 +1,89 @@
+# Version 1.0 WSDL Coverage Matrix
+
+Plan for turning WSDL and XSD support claims into automated, fixture-backed evidence before 1.0.
+
+See the root [README.md](../../README.md) for project overview and [Version 1.0 Roadmap Plan](README.md) for the complete 1.0 route.
+
+## Goal
+
+The project should have an automated feature matrix that proves which WSDL and XSD patterns are supported, partially supported, or rejected with diagnostics. The matrix should feed `docs/supported-patterns.md` and protect 1.0 from silent miscompilation.
+
+## Design Direction
+
+Each matrix row should have a minimal fixture, an expected support status, and a test that proves the status. A supported feature must compile and generate aligned client, OpenAPI, and gateway artifacts where applicable. An unsupported feature must fail with a clear diagnostic or be documented as intentionally out of scope.
+
+## Scope
+
+- Add a fixture directory for WSDL feature coverage.
+- Add a manifest that lists features, status, expected commands, and expected diagnostics.
+- Add Vitest coverage that reads the manifest and runs the relevant generation steps.
+- Update `docs/supported-patterns.md` from the matrix findings.
+- Include priority gaps from the roadmap.
+
+## Out Of Scope
+
+- Do not implement every unsupported WSDL feature in this slice.
+- Do not replace the existing weather fixture for smoke tests.
+- Do not make docs generated from the manifest unless that is a deliberate later decision.
+
+## Priority Feature Rows
+
+| Feature | Expected 1.0 Status | Notes |
+|---------|---------------------|-------|
+| `xs:choice` union mode | supported | Implemented in `0.26.0` |
+| `xs:union` | supported or diagnostic | Decide after fixture work |
+| Abstract types | diagnostic | Avoid silent concrete treatment |
+| Substitution groups | diagnostic | Avoid silent omission |
+| Multi-binding WSDLs | documented behavior | First binding or explicit selection |
+| External `PolicyReference` | partial or diagnostic | Inline policy already exists |
+| Deep composition | supported | Prove current recursion behavior |
+| `xs:anyAttribute` | diagnostic | Current support is not full |
+| MTOM/XOP attachments | unsupported diagnostic | Keep out of 1.0 scope unless required |
+
+## Manifest Shape
+
+The manifest should be small and reviewable. A JSON or TypeScript manifest is acceptable if tests can import it deterministically.
+
+```json
+{
+  "features": [
+    {
+      "id": "choice-union-simple",
+      "fixture": "choice-union-simple.wsdl",
+      "status": "supported",
+      "commands": ["compile", "client", "openapi", "gateway"]
+    }
+  ]
+}
+```
+
+## Testing Approach
+
+### Matrix Runner
+
+Create a Vitest suite that reads the manifest and executes the requested commands through programmatic APIs where possible. CLI smoke behavior should remain covered by existing smoke scripts.
+
+### Supported Feature Tests
+
+For supported rows, assert successful compilation, generated TypeScript type-checking, OpenAPI validation, and gateway schema generation when applicable.
+
+### Diagnostic Feature Tests
+
+For diagnostic rows, assert the exact error class or user-facing message shape. Avoid brittle full-message assertions unless the message is part of the public contract.
+
+### Documentation Tests
+
+Ensure every documented unsupported or partial feature has a corresponding matrix row. This can be a lightweight consistency test that compares feature IDs with anchors or explicit markers in `docs/supported-patterns.md`.
+
+## Acceptance Criteria
+
+- The matrix includes every roadmap priority feature.
+- Supported rows have passing fixtures.
+- Unsupported rows fail with clear diagnostics.
+- `docs/supported-patterns.md` reflects the matrix.
+- No known feature silently miscompiles in matrix coverage.
+- The matrix can run in CI or release preflight without network access.
+
+## Release Implications
+
+This slice may reveal features that should be implemented before 1.0. It may also justify explicit post-1.0 deferrals if diagnostics and documentation are strong enough.

package/docs/supported-patterns.md

@@ -12,7 +12,8 @@ These patterns are handled end-to-end: WSDL parsing, TypeScript type generation,
 - Type inheritance through `<xs:extension>` and `<xs:restriction>` on both simple and complex content
 - Nested XSD imports across multiple schema files with relative and absolute URI resolution
 - Multiple namespaces with deterministic collision resolution via PascalCase uniqueness
-- `<xs:choice>` elements modeled as parallel optional alternatives
+- `<xs:choice>` elements modeled as parallel optional alternatives by default
+- Opt-in `<xs:choice>` union mode with exclusive TypeScript branch unions and OpenAPI request constraints
 - Optional and nillable fields using `minOccurs`, `maxOccurs`, and `nillable` attributes
 - `ArrayOf*` wrapper types with automatic unwrapping in OpenAPI and runtime bridging in gateway code
 - WSDL/XSD documentation annotations propagated into TypeScript JSDoc comments and OpenAPI descriptions

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@techspokes/typescript-wsdl-client",
-  "version": "0.24.0",
+  "version": "0.26.0",
   "description": "Turn legacy WSDL/SOAP services into typed TypeScript clients, OpenAPI 3.1 specs, and production-ready Fastify REST gateways. Built for enterprise SOAP modernization.",
   "keywords": [
     "wsdl",
@@ -95,14 +95,14 @@
     "fastify": "^5.8.5",
     "fastify-plugin": "^5.1.0",
     "rimraf": "^6.1.3",
-    "tsx": "^4.22.3",
+    "tsx": "^4.22.4",
     "typescript": "^6.0.3",
-    "vitest": "^4.1.7"
+    "vitest": "^4.1.8"
   },
   "dependencies": {
     "@apidevtools/swagger-parser": "^12.1.0",
     "fast-xml-parser": "^5.8.0",
-    "js-yaml": "^4.1.1",
+    "js-yaml": "^4.2.0",
     "saxes": "^6.0.0",
     "soap": "^1.9.3",
     "yargs": "^18.0.0"