[🐞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.

[xsjcTony]

Sorry for the straight ping @jorisre , but this has been an issue that across multiple versions, and still an issue on the latest version: https://stackblitz.com/edit/vitejs-vite-vtw2ye?file=package.json,src%2F__tests__%2FDemo.test.tsx

[jorisre]

Hi @xsjcTony , I've created a working version of the code at this link: https://stackblitz.com/edit/vitejs-vite-6fcmk9?file=package.json,src/tests/Demo.test.tsx. Can you please review and confirm that this meets your expectations?"

[xsjcTony]

@jorisre Thanks for the solution. It did work for the minimal reprod I've given, but when I tried it in my real code, it doesn't work. I've modified the minimal reprod that I'm able to reproduce it, with another simplified real-world TextInput component. https://stackblitz.com/edit/vitejs-vite-vtw2ye?file=src%2FApp.tsx,src%2Fcomponents%2FTextInput.tsx,src%2F__tests__%2FDemo.test.tsx I tried to remove <T> from useForm there as you suggested, and it just breaks, because I'll need the <T> generic on useForm to let it pass down to the component.

[jorisre]

Your code is overly abstract, which is causing these errors, and I'm unable to assist you. I recommend simplifying your approach and following the documentation instead of passing down register instance:

<TextInput {...register('fieldName')} />

[xsjcTony]

Yeah I agree with you, but the codebase is already like that for ages. The main reason is that it's working correctly before v3.3.1 (working well in v3.3.0), so I'm assuming that there's some regression on that patch version. If it didn't work in the first place, I don't think I or any others will write the code that way.

[jorisre]

The 3.3.1 version fixes an issue when including optional keys in a Yup schema. This fix introduces a more restrictive type check, which triggers the error on your side. As I mentioned earlier, we do not recommend the usage of the resolver in the way you're doing it, and I'm unable to assist you further without introducing regressions on already resolved issues.

You have the following options:

• Identify and fix the problem, and I'll be happy to review your pull request
• Implement the resolver yourself within your codebase to meet your specific needs
• Update your code to follow our recommended approach