"Type instantiation is excessively deep and possibly infinite." when using Zod versions 3.23.0 and 3.23.1 together. about zod HOT 9 OPEN

I see what you're saying, but as some light pushback:

1. I've never seen this degree of incompatibility between patch versions of the same project (outside of an actual bug).
2. This significantly hampers the ability to publish a library of prefab zod schemas which would be consumed and extended by multiple consumers (our use case).
3. npm is explicitly designed to be able to handle various versions of a single package as sub-dependencies of direct dependencies, so the total incompatibility comes as a surprise in this case.

it's not clear what should be done about this.

That's totally fair — I don't have a solution either :)

If it's a "hard problem" to solve, so be it, but I'm sure it'll keep coming up, and it might be worth identifying the root cause and figuring out a medium-to-long-term solution.

from zod.

Having similar issue – zod seems to be grinding down to a halt in a forever error loop when using 3.23.x together with vee-validate/zod.

Downgrading to 3.22.4 solved the issue for now.

from zod.

I have this issue with 3.23.7 and 3.23.8. Having to remain on 3.23.6 for now.

from zod.

I described a similar scenario here: #3429 (comment)

It seems to be related to the recursive definition of ZodError. As far as I can tell this isn't related to Zod 3.23 and can be replicated with almost any two previous versions of Zod (let me know if you have evidence to the contrary though).

As I mentioned in the other issue, it's not clear what should be done about this. There are breaking changes I can make that might mitigate the problem (changing the definition of ZodError). But really modern monorepo tools and package managers have systems to avoid dependency duplication for exactly these reasons.

from zod.

I am experiencing the same issue as well. We are dealing with a large schema that is causing a significant slowdown in the project, especially when importing the schema to our working file. We attempted to resolve the issue by downgrading to version 3.22.4, but it did not have any effect.

from zod.

I had the same issue here after upgrading to 3.23.X. Downgrading worked for me.

from zod.

I had the same issue in a mono repo with 2 packages using 3.23.6 and one using 3.23.5. I got them all on the same version and issue was fixed.

from zod.

Had the same issue with two repos 3.23.6 & 3.23.5. Updated 5 to 6, and the errors are gone.

from zod.

I have this issue with 3.23.7 and 3.23.8. Having to remain on 3.23.6 for now.

This worked for me too, cheers! 🍻

from zod.