Skip to content
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 types when using optional property with nested structure and deep option #77

Closed
monisnap-paul opened this issue Aug 6, 2021 · 7 comments · Fixed by #112
Closed

Comments

@monisnap-paul
Copy link

monisnap-paul commented Aug 6, 2021

When using optional properties in a type and the option deep: true, the nested type is not properly converted to camelcase.

Screenshot 2021-08-06 at 14 08 34

Here is a repository which reproduces the error.
https://github.com/monisnap-paul/camelcase-keys-bug

@sindresorhus
Copy link
Owner

// @g-plane

@g-plane
Copy link
Contributor

g-plane commented Aug 8, 2021

This may be able to be fixed, but the "optional" mark will be lost as the given example. For example:

type Source = { a?: string }

will become:

type Result = { a: string | undefined }

These are different in TypeScript.

@monisnap-paul
Copy link
Author

There are actually two issues with the given example:

  1. "City" and "Country" properties in the type are not properly converted to camelcase
  2. "?" is not equivalent to "| undefined"

@g-plane
Copy link
Contributor

g-plane commented Aug 23, 2021

"?" is not equivalent to "| undefined"

I know, but we can't operate: TypeScript playground.

@salemhilal
Copy link

I wanted to bump this. It seems like even if { someKey?: string} is different than { someKey: string | undefined }, that's probably a level less important than having the type be { some_key?: string } but having the actual value be { someKey: string | undefined }.

If that's a cool assumption to make, I'd be open to submitting a patch for this issue.

@RichiCoder1
Copy link

Ironically I think this fix for this is to use the type CamelCasedPropertiesDeep from type-fest.

@jandolezal71
Copy link

I wanted to bump this. It seems like even if { someKey?: string} is different than { someKey: string | undefined }, that's probably a level less important than having the type be { some_key?: string } but having the actual value be { someKey: string | undefined }.

If that's a cool assumption to make, I'd be open to submitting a patch for this issue.

Output type should be { someKey?: string | undefined } or { someKey?: string }.

In some cases you don't want to pass keys with undefined values explicitely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants