-
Notifications
You must be signed in to change notification settings - Fork 574
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
Supporting exactOptionalPropertyTypes #2111
Conversation
`signal` key has defined its key as optional, not necessarily the value even though this happens implicitly. No key means no value which translates to `undefined`: ```ts signal?: AbortSignal | null; ``` To support `exactOptionalPropertyTypes` it would have to be defined as: ```ts signal?: AbortSignal | null | undefined; ``` While you could say the key isn't optional (removing `?`), which then requires an explicit `undefined` value: ```ts signal: AbortSignal | null | undefined; ``` That would require an explicit undefined being passed. Given this key is part of TS definitions and module augmentation is overkill, just "oring" from undefined to an expected value (in this case `null`) solves the problem.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we can use Maybe
type in this case
Thanks for the PR! |
YogaServerOptions
has a bunch of keys that are defined as optional, but haven't declared their value as such, even though this happens implicitly since no key means no value which translates toundefined
:To support
exactOptionalPropertyTypes
and retains its API it would have to be defined as:While you could say the key isn't optional (removing
?
), which then requires an explicitundefined
value:That would require an explicit undefined being passed and would break builds and alter its API.