search

react-hook-form / resolvers

📋 Validation resolvers: Yup, Zod, Superstruct, Joi, Vest, Class Validator, io-ts, Nope, computed-types, typanion, Ajv, TypeBox, ArkType, Valibot, effect-ts and VineJS
https://react-hook-form.com/
MIT License
1.71k stars 155 forks source link

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

Open xsjcTony opened 12 months ago

xsjcTony commented 12 months ago

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 image

Desktop (please complete the following information):

OS: Windows 11 Browser: Chrome Version: 116

nachodevify commented 12 months ago

did you find any workaround?

willd-mwp commented 11 months ago

@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 commented 11 months ago

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 commented 10 months ago

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 commented 9 months ago

any updates here?

Kizmar commented 9 months ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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: