Yup: bug after update 0.31.1 -> 0.32.0

[TrejGun]

Describe the bug
types seems to be broken

To Reproduce

import * as Yup from "yup";

export const validationSchema = Yup.object().shape({
  email: Yup.string(),
});

Expected behavior
No types error

Additional context
i was using 0.31.1 with @types/yup but 0.32.0 does not need them

[kirintwn]

Same here, forced to rollback to 0.31.1 for now.

[Cyral]

Also had to roll back

[lednhatkhanh]

Same here, had to rollback

[Cyral]

The changelog indicates some kind of breaking change but the README is not updated on how to use the new imports.

👎

[msheakoski]

TypeScript usage is linked in the README. Basically, remove @types/yup, add strictFunctionTypes:false to tsconfig.json, and maybe a couple small adjustments listed in the TypeScript guide.

[TrejGun]

@types/yup is removed
but why should I set strictFunctionTypes:false for the rest of my app because of one lib

for now it seems like a breaking change which should come in major update

[davewasmer]

@msheakoski I don't think forcing the consuming application to reduce the strictness of their type checking is an ideal solution here. If yup is unable to accurately represent it's behavior with Typescript's types, then I think the solution is to fall back to less strict typing of yup as a library (i.e. using anys where necessary), which lets consuming apps retain the higher degree of strictness in the rest of their code.

[msheakoski]

@davewasmer I'm just an early adopter sharing the changes that I read in the TypeScript usage docs. Let's see what the author says.

[vtrphan]

i'm having issues too, falling back to 0.31.1 for now

[MariusMeiners]

rolling back to 0.31.1 and installing @types/yup also solved it for me for now

[artpumpkin]

Same here

[jquense]

Not a bug folks. The typing needed to actually implement the library in TS requires a lot more shenanigans than writing .d.ts files, and at the moment require strictFunctionTypes: false. I appreciate that folks don't want to reduce the strict-ness of their TS project. In practice this is not as bad as it might seem. TS already ignores this setting for class methods and constructors and checks them bivariantly. Turning this off (in my experience at least) doesn't cause more bugs (tho it can) but does reduce the need for explicit down-casting is lots of places it's otherwise silly to need.

To be clear though I would be happy to remove this restriction, I don't have endless time to tweak TS types, so can't promise that it will happen soon. If someone wants to help out more than happy to take improvements. In the meantime if the check is a deal breaker options are:

• Keep strictFunctionTypes on and manually cast problem schema to AnySchema or any for edge cases (see note below)
• Stick with 0.31, and the DT types. note tho that the DT types are _less_ correct than the include ones, and (imo) more likely to lead to issues in a project than disabling this check, but everyone's milage will vary choose what works best for you!

for now it seems like a breaking change which should come in major update

There is a ton of breaking type changes so yes it did come with a major update. 0.31.0 -> 0.32.0, that is the versioning convention used by npm and yarn for <1.0.0 projects the, left most version bumps.

[jquense]

As an addendum, 0.32.1 fixes (inadvertently) the most limiting case that needed strictFunctionTypes, object shapes:

object({
  name: string()
})

should now work fine with strict on, there are a few other cases that still don't, namely some concat() usages, but I suspect those are easier to work around with casts in the meantime.

[MariusMeiners]

thanks for the explanation 👍

[IvanKalinin]

It also have issue with Lazy schema.

```(property) childNodes: Yup.ArraySchema | Reference | Lazy>, {
meta: Yup.ObjectSchema | Reference<...> | Lazy<...>>, {
...;
}>, Record<...>, TypeOfShape<...>, AssertsShape<...>>;
}>, Record<...>, TypeOfShape<...>, AssertsShape<...>>, Record<...>, TypeOfShape<...>[] | undefined, AssertsShape<...>[] | undefined>
Argument of type 'Lazy' is not assignable to parameter of type 'AnySchema'.
Type 'Lazy' is missing the following properties from type 'BaseSchema': deps, tests, transforms, conditions, and 37 more.

And yes, I've added those options in my tsconfig.json

"strictFunctionTypes": false,
"strictNullChecks": true,

```

[jquense]

@IvanKalinin update to 0.32.1

[IvanKalinin]

[jquense]

open up another issue with this specific one please!

[harshzalavadiya]

There can be issue for those who are not using TypeScript in strict mode

For me I was able to temporary supress this and be on latest package by disabling typecheck only for src folder
https://stackoverflow.com/questions/40164034/typescript-strictnullchecks-with-limited-scope

is there any other way possible?, because having flexible strictnullchecks might be nice instead of enforcing it on everyone

[jquense]

@harshzalavadiya yup will likely never support strictNullChecks being off. Yup as a validation library (and runtime type checker) makes the distinction between undefined and null and needs TS to do the same in order to be accurate

[harshzalavadiya]

@jquense okay, then enabling strict null checks is the way to go then, It's a hassle for one time but might be worth

Anyway thanks for all of your hard work in yup you are doing amazing job :+1:

[mikecousins]

Switching to any or AnySchema doesn't work with Formik:

[jquense]

Formik needs to update the types it's using