[🐞Yup] TypeScript error in unit-test wrapper after upgrading to v3.3.1

[xsjcTony]

Describe the bug
Hey, the Type error happened after upgrading to v3.3.1, and I'm using generic to create a wrapper with react-hook-form in my unit test.
It's a regression since it's working well in v3.3.0.

I raised a similar issue last time but it ended up saying it's not a hookform/resolver issue and being transformed into the discussion, but it ACTUALLY IS. It's fixed in several releases after, but this time it's a different issue and I'm pretty sure it's because of the last release v3.3.0 -> v3.3.1
For reference: https://github.com/orgs/react-hook-form/discussions/10160

To Reproduce
Open link below

Codesandbox link (Required)
https://stackblitz.com/edit/vitejs-vite-zkuudx?file=src%2F__tests__%2FDemo.test.tsx

Expected behaviour
A clear and concise description of what you expected to happen.

Screenshots

Desktop (please complete the following information):

OS: Windows 11
Browser: Chrome
Version: 116

[nachodevify]

did you find any workaround?

[willd-mwp]

@jorisre

Is there a possibility of yourself or one of the other regular maintainers investigating this bug. we've also encountered it an have had to keep our @hookform/resolvers version on 3.3.0 instead of upgrading to 3.3.1`

[Kizmar]

Same here. We were on 3.2.0 and upgraded straight to 3.3.1 and ran into the same error. Reverted to 3.3.0 and it's working again.

[crow7m]

same here, after a minor version update, getting an error that the schema wont match, before, we didn have to specify the types for the resolver function where there are conditional or non-required fields, after rollback to 3.0.0, it works fine
any ideas here

[JohannesFeige]

any updates here?

[Kizmar]

In our case, it was an issue with one of the validators using Yup.string() on a property that was marked as "any". Once we changed the "any" property to a "string", the error went away.

That scenario worked in prior versions, and didn't otherwise throw any errors or warnings that we noticed. The "any" type was old in this case, should have been a "string" anyway. So we lucked out.

Seems like the OP issue may be specific to using generics.