Unexpected TS types for _id and _v in inferred types, particularly for subdocument arrays #12959
Open
2 tasks done
Labels
typescript
Types or Types-test related issue / Pull Request
Milestone
Prerequisites
Mongoose version
6.9.0
Node.js version
16.18.1
MongoDB server version
4.4.18
Typescript version (if applicable)
4.9.4
Description
I'm encountering a few unexpected behaviors with the types being inferred from both schema helpers (
InferSchemaType
andHydratedDocumentFromSchema
), the resulting types when executing a model method, and the resulting types when converting that result to a POJO., particularly as it pertains to subdocument arrays. The included sample code hopefully tells the story, but this is a summary of what I have found that feels incorrect.Subdocument Array inference is returning types for
_id
and__v
when usingInferSchemaType
This is less of an error than a surprise based on what I read in #11967. As per that issue,
InferSchemaType
does not return an_id
type. Although it's not indicated in that issue, it also doesn't have a type for__v
but that seems to be consistent with not having an_id
type. However, I was very surprised to see that subdocument arrays DO have a type for the_id
and the__v
value. It seems like neither the parent document nor the subdocuments should have these types.Hydrated documents have wide types for
_id
and__v
for subdocument arraysI ran my schema through
HydratedDocumentFromSchema
. This correctly provided a type ofmongoose.types.ObjectId
for the parent document's_id
property. However, the subdocument arrays have a type ofmongoose.Types.ObjectId | undefined
. I would have not expected this to be an optional property.Additionally, the types for
__v
on both the parent document as well as the subdocuments isany
with the optional flag. I traced through some history and it seems likeany
was put there instead of number to try to avoid some other issues. I was surprised to see the optional flag on this type, although withany
it just widens it toany
, so maybe it doesn't matter. If this type ever was able to be more accurate and benumber
then I wouldn't think this should benumber | undefined
.Document instance exhibits the same types as the
HydratedDocumentFromSchema
This seems to track as I would expect them to be consistent with each other. However, all of what I described that feels off in that section also applies to the document instances.
Document instance converted to POJO additionally lacks a type for
__v
After running a document instance through
toObject()
, the resulting object does not have a type for the__v
property on the parent document, although it is a valid property on the subdocuments. This surprised me, because a type ofLeanDocument<HydratedDocumentFromSchema<typeof schema>>
does have an__v
property, so there is a behavioral difference between those two things.The POJO also continues to have the same types as
HydratedDocumentFromSchema
otherwise the things I feel like are off with that are also off here.Steps to Reproduce
Expected Behavior
_id
and__v
properties for consistency when usingInferSchemaType
._id
in a subdocument should be based on the schema options value for_id
. If the option is set tofalse
then there should be no_id
property on a subdocument. If the value is set totrue
or left as default then_id
should not be optional and should be an ObjectId. This applies to the inferred Hydrated types as well as the document instance types.__v
in both parent and subdocuments should be based on the schema options value forskipVersioning
. IfskipVersioning
istrue
then there should be no__v
property. IfskipVersioning
isfalse
or left as default then__v
should be anumber
. This applies to the inferred Hydrated types as well as the document instance types.__v
should be a valid property for documents converted to POJO format.The text was updated successfully, but these errors were encountered: