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

version 4.17.1,the type of the data variable is inferred to never by _.has #69528

Closed
xujintai123 opened this issue May 6, 2024 · 6 comments · Fixed by #69534
Closed

version 4.17.1,the type of the data variable is inferred to never by _.has #69528

xujintai123 opened this issue May 6, 2024 · 6 comments · Fixed by #69534

Comments

@xujintai123
Copy link

xujintai123 commented May 6, 2024

issue:
on 4.17.1 version,the type of the data variable is inferred to never by _.has。
image

source of problem:
#69291
1c01676#diff-0740e38db2dd38b18fb8612ceef08349585a3d898fb6ad21522819b8677804f7

@xujintai123 xujintai123 changed the title version 4.17.1,_.has Type changed cause type error version 4.17.1,_.has Inferred type error May 6, 2024
@xujintai123 xujintai123 changed the title version 4.17.1,_.has Inferred type error version 4.17.1,variable was Inferred type error by _.has May 6, 2024
@xujintai123 xujintai123 changed the title version 4.17.1,variable was Inferred type error by _.has version 4.17.1,the type of the data variable is inferred to never by _.has May 6, 2024
@aj-r
Copy link
Contributor

aj-r commented May 12, 2024

I'm surprised it narrows the type to never - we have tests to ensure the type remains T when _.has returns false.

I'm guessing the issue is that data's type requires level to be set, so our type guard simplifies to object is T. Thus typescript thinks _.has can never return false, which would be correct as far as the type system is concerned.

Why do you need to use _.has() in this case? Can you simply remove it and assume the property is set? If not, consider changing the type to make the property optional. Or use Object.hasOwnProperty() instead.

@aj-r
Copy link
Contributor

aj-r commented May 12, 2024

Ah, I just noticed #69534 which should fix this.

@xujintai123
Copy link
Author

xujintai123 commented May 13, 2024

I'm surprised it narrows the type to never - we have tests to ensure the type remains T when _.has returns false.

I'm guessing the issue is that data's type requires level to be set, so our type guard simplifies to object is T. Thus typescript thinks _.has can never return false, which would be correct as far as the type system is concerned.

Why do you need to use _.has() in this case? Can you simply remove it and assume the property is set? If not, consider changing the type to make the property optional. Or use Object.hasOwnProperty() instead.

its historical code,cause compilation error after upgrade to 4.17.1.

@tidhar-ziv
Copy link

This issue is still not solved in version 4.17.4

import _ from "lodash";

function test(doc: any) {
    if (_.has(doc, "something")) {
    }
    else {
        doc["something"] = true;
    }
}

This code will trigger "TS2322: Type 'boolean' is not assignable to type 'never'."

@aj-r
Copy link
Contributor

aj-r commented May 19, 2024

That seems like reasonable behavior IMHO - if TS thinks the propery doesn't exist then it won't let you set it. If you want to treat the object as a map, use something like Record<string, boolean> (or maybe Record<string, any>) instead of any.

@tidhar-ziv
Copy link

tidhar-ziv commented May 19, 2024

equivalent non lodash code doesn't give an error:

function test(doc: any) {
    if (doc.hasOwnProperty("something")) {
    }
    else {
        doc["something"] = true;
    }
}

the type of doc is "any", why would _.has change that? not sure it's lodash job to "discipline" developers, so shouldn't be too opinionated regarding the use of "any". Anyway this is a breaking change, as that was not the behavior prior to version 4.17.1

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.

3 participants