I spent some time looking in the code base and trying to understand how the models for this case are built (and how they are "composed" together).
I got some basic understanding but not enough to produce a PR with a fix.
If you agree with the expected result & can point me in the right direction, then I can take a poke at writing some code to achieve this result (and a test case).
FYI: the same semantics can be achieved with a root schema of (roughly) anyOf: [{a, b}, {a, c}], where ALL props are described in each schema of anyOf. but this is a little annoying to work with, and validation libs (ajv) that use the same schemas produce poor validation results (duplicate errs if "a" is invalid - one err for each sub schema).
Description
a common use case of "anyOf" is to describe "either field A or B is required".
example schema where "a and (b or c)" are required:
running
@hey-api/openapi-ts
on this kind of schema produces a type which simple does an "OR" an the anyOf schemas and the "main" schema:more correct result that keeps the semantics (of b or c are requried) would be:
I spent some time looking in the code base and trying to understand how the models for this case are built (and how they are "composed" together). I got some basic understanding but not enough to produce a PR with a fix.
If you agree with the expected result & can point me in the right direction, then I can take a poke at writing some code to achieve this result (and a test case).
FYI: the same semantics can be achieved with a root schema of (roughly)
anyOf: [{a, b}, {a, c}]
, where ALL props are described in each schema of anyOf. but this is a little annoying to work with, and validation libs (ajv) that use the same schemas produce poor validation results (duplicate errs if "a" is invalid - one err for each sub schema).Reproducible example or configuration
npx @hey-api/openapi-ts -i ./api.yaml -o ./out
OpenAPI specification (optional)