Colin McDonnell

Okay, I've replicated. This is because Zod relies on some internal subpath imports, which aren't supported if the user has `"moduleResolution": "node"` in tsconfig. Bummer. I'm going to refactor to...

Can you try this again with the latest beta? Note that you'll need to refactor your imports: https://github.com/colinhacks/zod/pull/4364

Zod 4 is now published to JSR: https://jsr.io/@zod/zod

Here's a dedicated guide for library authors that answers some common questions: https://v4.zod.dev/library-authors 1. Best practices around peer dependencies 2. How to support Zod v3 and Zod v4 simultaneously 3....

Sorry, that's an oversight. I made some usability improvements in `[email protected]`. Use `.def` to access the input & output schemas: ```ts const myFn = z.function({ input: [z.string()]. output: z.number() });...

Thanks for the PR. While I think it's a compelling use case, I think it can already be adequately represented with something like this: ```ts const anyString = z.custom((v) =>...

Strongly opposed to this. Makes type inference far more difficult (should both properties be optional in the inferred type). I don't like an API like `.secondaryName()` that only impact parsing...

Fixed and landed in `[email protected]`

Short answer: don't pass an explicit generic to `useForm` anymore. The schema types are all inferred now. Unfortunately the code example from the website (`useForm(...)`) is unsound and assumes the...

cc @quocluongha @wengkhing I believe all of this is working as intended. These inferred types are correct.  If you want to modify the input type for a coerced schema,...