Union type preference by pdfowler

[xddq]

Summary

@pdfowler Hey!

First of, sorry for not commenting your PR but rather directly adapting it. The main changes were simply based on the decision to only support Type.Union instead of enums and unions for now. I added you as a colaborator to the repo so you can review this PR. Please wait for my approval when merging PRs. I will merge this one after a while if you have no time for a review.

Adapting the work of @pdfowler to my preference/decision of generating union types (and only union types for now) for JSON schema objects of type "enum". My main reasons for this decision:

• it makes the code way easier to maintain (as reflected by the diff in this commit). The codegen code gets easier, less dirty global state, easier testing. The decision to use global state for the enum code was painful for me anyway but I decided to do it to get the feature done. The pain is somewhat reflected in the initial comment here and here but I was to lazy to adapt the collect code.
• I agree on the mentioned state of enums in Typescript mentioned by a comment here. I want to push for using unions as thats what I commonly use and see anyway.

If this PR is merged the pr here will be closed.

After merge a new release (1.5.0) will be created.

[xddq]

@pdfowler Hey!

Feel free to create another PR when you got time for it. I think doing this one-by-one makes it easiest for both of us. I would prefer features/bug fixes over cleanups, since I have planned to do a clean-up of the code myself (of the code that is already existing)

Somewhat unfortunate that you have an internal fork where you are keeping the configuration (in terms of merge conflicts when doing changes in both repos). I hope this does not amount to to much work!

If there is anything open/not implemented yet, feel free to just create an issue. I will probably tackle it in the following days/week.

[pdfowler]

That all sounds good. For next steps I think that I'm going to write up some details of my use case so I can clarify some of the reasons I've done what I've done. Some of that work is now redundant with the inlining of union types you did here, so I'll focus on rebasing support for more use cases PR #23

Agree on the internal fork, but it's necessary at this point. I needed to push ahead with the code that I needed to solve our problems (and also some internal/private config). This is on an "internal" branch, and our main branch still follows upstream (any new work im branching off of upstream/main). So far, the merge issues have been minimal, and I will continue to reevaluate the "extra" code I have internally to make sure we can stay in sync.