-
-
Notifications
You must be signed in to change notification settings - Fork 127
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
Fix the .get()
TypeScript return type
#117
Conversation
.get()
TypeScript return type
expectType<string | undefined>(conf.get('foo')); | ||
expectType<string>(conf.get('foo')); |
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.
The second one was indeed incorrect. But Is it correct to assume that a value will never be undefined when we do not pass a default? I think we should still make it possible to be undefined to encourage people to handle an undefined state.
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.
Yes, value will never be undefined unless developer make a bug such in this test, type UnicornFoo
is source of truth.
type UnicornFoo = {
foo: string;
};
const conf = new Conf<UnicornFoo>({accessPropertiesByDotNotation: true});
Maybe we should validate default
option, but it is out of scope of this PR.
Like this
defaults?: Readonly<{
[P in keyof T]: Exclude<T[P], undefined>
}>;
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.
Maybe we should validate default option, but it is out of scope of this PR.
That would be nice, yes, but I agree, it should be a separate PR.
Thanks for fixing this, @SnosMe 🙌🏻 |
Closes #116