Skip to content

Bug: KeysByType includes undefined #106

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

Closed
krisdages opened this issue Jun 13, 2019 · 2 comments
Closed

Bug: KeysByType includes undefined #106

krisdages opened this issue Jun 13, 2019 · 2 comments
Labels

Comments

@krisdages
Copy link

Looks like for some reason undefined is getting included in the result for KeysByType

interface Obj { a: string; b?: number; }

type StringPropertyKeys = KeysByType<Obj, string>; // "a" | undefined
const x: StringPropertyKeys = undefined; // no error

type CorrectStringPropertyKeys = Exclude<KeysByType<Obj, string>, undefined>; // "a"
const y: CorrectStringPropertyKeys = undefined; // error
andnp added a commit that referenced this issue Jun 14, 2019
Because status modifiers are attached to keys, `KeysByType` gives back
an `undefined` key when the original object contains optional keys; even
if the optional key is not of the given type. This change fixes that by
removing the optional status modifier from the object while iterating
over the keys.

The downside to this change is that it does not perfectly purify the
object. So if other status modifiers are added in the future, we will
not necessarily be robust to that change. A more "pure" fix (pun
intended) would be to work with a purified object. The downside is that
the only way I could figure out to do that would require much uglier
code and/or a helper function that would need to be exported. In favor
of minimizing "private" exports, I opted for the simple solution.

Also a downside here is that we cannot filter by `undefined` if a key
is optional. This was already an issue before this commit, so I'm
punting on it for now because the fix seems non-trivial.

Closes #106
andnp added a commit that referenced this issue Jun 14, 2019
The regression test makes sure that this PR actually solves the problem
that was brought up in issue #106. It also adds a failing test case for
a bug that I noticed while making the fix. Since my ad hoc testing
solution obviously does not allow for known failures (which I guess is,
on its own, a known failure..), I annotated this with a comment. There
is obviously a lot of work to be done on the testing side of this
library.
@andnp andnp mentioned this issue Jun 14, 2019
@andnp
Copy link
Owner

andnp commented Jun 14, 2019

Thanks for pointing this out! I've added a PR (#108) that should fix this issue. It also alerted me to another issue with KeysByType that I wasn't able to fix yet:

interface Obj { a: string; b?: number; }

// should be `b`, but is `never`
type got = KeysByType<Obj, undefined>;

andnp added a commit that referenced this issue Jun 25, 2019
The regression test makes sure that this PR actually solves the problem
that was brought up in issue #106. It also adds a failing test case for
a bug that I noticed while making the fix. Since my ad hoc testing
solution obviously does not allow for known failures (which I guess is,
on its own, a known failure..), I annotated this with a comment. There
is obviously a lot of work to be done on the testing side of this
library.
@andnp andnp closed this as completed in a9eaa4b Jun 25, 2019
@andnp
Copy link
Owner

andnp commented Jun 25, 2019

🎉 This issue has been resolved in version 3.2.2 🎉

The release is available on:

Your semantic-release bot 📦🚀

@andnp andnp added the released label Jun 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants