Create separate generic for schema definition #13856
Conversation
|
Hello 👋 Sorry for being inactive lately, I will try to find time to get more involved again. |
There was a problem hiding this comment.
Looks OK, it is really not ideal to require explicit casting or redundant as const in some places, as long as it is limited to the string representation (of primitives) it should be OK
i have not yet tested this change (or 8.0 in general) against typegoose for type issues
| @@ -95,14 +95,15 @@ async function autoTypedVirtuals() { | |||
| const testSchema = new Schema({ | |||
| email: { | |||
| type: String, | |||
| required: [true, 'email is required'] | |||
| required: [true, 'email is required'] as [true, string] | |||
There was a problem hiding this comment.
are those array castings really required instead of as const?
There was a problem hiding this comment.
Unfortunately yes. I think that's more of a TypeScript 5 issue though, similar to #13514.
|
I'm going to close this PR for now, and postpone the task of automatically inferring hydrated document type to a future release. There's just too many surprise test issues related to this PR that I am unable to understand, so my confidence level in this PR is low. We'll leave this branch as an informational branch for future work. |
Summary
Re: #13523, #13772.
The current implementation of automatic type inference makes it tricky for us to automatically infer the correct hydrated document type. Because automatic type inference infers the
DocType, which is a mix of the hydrated document type and the raw doc type: hydrated for arrays and maps, raw for everything else, including nested paths. And then we infer the schema definition type from theDocType, which means we lose whether object paths are nested paths or subdocument paths.This PR presents one approach that can help us move towards automatically inferring the raw doc type and the hydrated doc type correctly: getting the schema definition and inferring the raw doc type from that. In theory, if we have the schema definition type, we should be able to infer the hydrated document type from that.
The downside is this approach seems to require adding
as constto schema definitions if you want to usetype: 'String'ortype: 'Number'as opposed totype: Stringortype: Number. Also has some issues with context for default functions, but those issues are present to some extent even without this PR and have easy workarounds.cc @mohammad0-0ahmad
Examples