yup: bug after update 0.31.1 -> 0.32.0

@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

@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.

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.

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.

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

@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 👍

open up another issue with this specific one please!

@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.

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.

Same here, forced to rollback to 0.31.1 for now.