feat: improve support for Enum types, Nullable Literals, Unknowns, etc

[pdfowler]

Summary

I'm in the process of migrating our mongoose schemas to TypeBox as a part of our recent upgrade to Feathers v5. Our data model contains over 100 mongoose schemas with a large variety in usage including child schemas, discriminated types, enums, and much more. This PR is the end result of my local updates to the library to get our schemas generated

Process

I wrote a crude ts script to either take a service name, or map over all service directories. For each service it does the following:

1. load the mongoose model and schema
2. use the mongoose-schema-jsonschema library to extract the json-schema representation of the mongoose schema
3. pipe the json-schema into ts2typebox schema2typebox
4. write the result to services/${serviceName}/schema.ts

Changes

• feat: initial support for Type.Union vs Type.Enum
• feat: add support for arrays of enum types
• feat: add support for "unknown" object types with no properties
• fix: improve support for nullable literal types (eg: type: ['string', 'null'])
• chore: begin work on disambiguation of nested Enum/Union types
• chore: update errors to include property name where error was thrown
• refactor: break out some utils into separate file

TODO

• [ ] Test coverage
• [ ] Documentation
• [ ] Break apart if necessary

[pdfowler]

@xddq I'm new to the project (obviously) and wanted to share what I have done to handle a number of edge cases that I encountered while running our models through it. LMK what you think and how you'd like to proceed. Seriously appreciate your efforts here!

[xddq]

@pdfowler Hey!

Thanks for the effort! Glad that you want to contribute your work back into the project!

pipe the json-schema into ts2typebox

I assume you mean schema2typebox :p

Enums, Unions

You bring up a valid point with enums being somewhat controversial in "modern typescript". I rarely see or use them as well, and rather default to unions. I would say we could default to implement enums as unions. This will make the codegen easier to reason about and the generated code more "typescript like". I would advocate against adding additional knobs and toggles for generating enums. We can think about adding them in case people raise issues with valid/valueable arguments for them.

Nullable literal types

Interesting. We should add support for these! I didn't know you could use these in JSON schemas and therefore they were not be implemented. If I am seeing it correctly, it is not defined in the draft-06 which I did use as baseline. However, it is specified in draft-07.

Proceeding

• I would want to split this PR into several PRs, each targetting a specific feature.
• Tests for the new features or bug fixes are required. This is to be able to keep the time investment low in the long run. I hope this is no dealbreaker, there are many examples and adding new ones should hopefully not be that complicated.
• You are obviously more than welcome to do this on your own. I will provide timely feedback for PRs. But we can also share/split the tasks. For me to do them I would want additional information (see chapter below). How much work will you put into this, have any plans?

Additional Information

If you want me to help you implement these features, please provide additional information, probably best via seperate issues. There is an issue template, but the info basically boils down to:

• a minimal schema that was used
• a description (expected outcome, generated outcome)

Again, thanks for your post! Open to thoughts and suggestions : ]

[pdfowler]

I think we're well aligned on all points. Let me finish my current push and then I'll get into the details here.

[xddq]

@pdfowler hey!

Just checking by since it has been two weeks now. What is your plan or your next steps here? It's okay if you don't have the time or simply don't want to continue. I just want to know what's up.

Creating issues as described in the previous post would still help me tremendously in fixing them, if you got time for that!

[pdfowler]

This has been part of a much bigger push and I've been down in the weeds getting all of our service types migrated to a new typed client. I'm coming up for air now and will take a pass at breaking things up this week and next.

I'll be starting with the union types, and moving ahead from there

[xddq]

@pdfowler Alright, awesome!

I will probably add support for typebox 0.30 as well as clean up the code base (a little bit) in the next weeks. But it should not get into the way :]

[pdfowler]

Closing in favor of other (discrete) PRs