[BUG][Typescript] modeling anyOf vs oneOf

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• What's the version of OpenAPI Generator used?
• Have you search for related issues/PRs?
• What's the actual output vs expected output?

Description

I noticed there is a lack of support for the open api 3 anyOf operation in most of the typescript templates. There are quite a few implementations of oneOf using typescript unions. Based on my reading of the spec and understanding of typescript I would expected that anyOf would be implemented via a type union and oneOf would be something more complicated which doesn't have native syntax support for in typescript. I wanted to gather the thoughts of those who have worked on these implementations.

This paragraph indicates that oneOf should not be allowed to match more than one of the types listed.

I was expecting it to be implemented something more like an exclusive-or. Some google around turned up this informative blog post on the subject.

Is this differentiation useful to people? Would a change like this horribly break users of generated typescript libraries? Am I missing something here? Thanks for your time.

@petejohansonxo @eriktim @macjohnny @karismann @SAnDAnGE

To divulge a little about my interest in this, I've been using a typescript framework call TSOA which generates an open api spec using the typescript interfaces and annotations attached to the controllers of our api server. It's really a great project. We're then generating a typescript client for our admin tool using the typescript-fetch openapi generator. It's been an interesting experiment to see what typescript goes in and what comes out on the other end. We've come to a point where we need this union support working and so I've started to investigate an implementation.

Start by reviewing the TypeScript templates and the typescript-fetch generator, then compare how OpenAPI anyOf and oneOf are currently represented in generated types. The issue does not name files, tests, or a settled expected output; maintainers would need to agree on the semantics and compatibility impact before “done” can be defined.