-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect inferred type for the empty object Type.Object({})
.
#888
Comments
@sdeprez Hi,
This is somewhat intentional (and partially historical) but mostly a consequence of TObject types not factoring additionalProperties constraints in inference (although the permissible number and string assignments are unfortunate). I think to provide better inference here, TObject should infer as one of the following depending on the whether additionalProperties has been specified. For example, consider the following (where an empty object without constraints is permissible of additional properties) const T = Type.Object({}) // type T = Record<PropertyKey, unknown>
const S = Type.Object({}, { additionalProperties: false }) // type T = Record<PropertyKey, never>
const U = Type.Object({}, { additionalProperties: Type.Number() }) // type T = Record<PropertyKey, number> Unfortunately, this leads to some fairly awkward scenarios. const T = Type.Object({
x: Type.String(),
y: Type.String(),
z: Type.String(),
}, {
additionalProperties: Type.Number()
})
type T = Record<PropertyKey, number> & {
x: string,
y: string,
z: string
}
const a: T = { // error unassignable: property values of string
x: '1', // are not number
y: '2',
z: '3'
} Do you have any thoughts or suggestions regarding the appropriate inference when factoring the above additional Property constraints? Open to discussion on this. Cheers |
Thanks for your detailed response! I agree that if we factor For the record, I'm using this great library ;) typebox inside |
@sdeprez Hi!
Yeah, let me have a think about this. I think if making changes to TObject inference, I'd want to factor the additionalProperties in that inference. Similarly based on #889, I think there is also a case to consider factoring unevaluatedProperties in inference too (where this issue highlights some of the cross over between inference, types and runtime assertion logic). Ill add a consideration tag to this issue and take a technical deep dive on it next time I get to sit down with the code. However given the complexity and general changes required, I wouldn't expect this functionality to land until the next minor revision (scheduled later on this year), but will see how things go. Will keep you posted! |
@sdeprez Hiya, I've given this quite a bit of thought, but will probably defer here for now. At this stage, I am keen to keep on with the open Will close this issue now, but keep these tags here for future review. Will ping on this thread should there be any changes down the road. Cheers |
Code:
In that case, the type of
T
is{}
, which in Typescript actually validates every non-null values, so the following assignments are all valid:One way to really represent the empty object type would be to use
Record<string, never>
which behaves the way we want, see https://www.totaltypescript.com/the-empty-object-type-in-typescript.The text was updated successfully, but these errors were encountered: