Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Type instantiation is excessively deep and possibly infinite." when using Zod versions 3.23.0 and 3.23.1 together. #3435

Open
kerrigan-nm opened this issue Apr 23, 2024 · 8 comments

Comments

@kerrigan-nm
Copy link

We have multiple projects using Zod, and are currently tripping over a compatibility issue between a project which is still on zod 3.23.0 and one which we're attempting to upgrade to 3.23.3.

Consuming the 3.23.0 schemas from 3.23.3 results in the following error, which I've also reproduced between 3.23.0 and 3.23.1.

error TS2589: Type instantiation is excessively deep and possibly infinite.

Full reproduction here, with a summary in the readme.

@colinhacks
Copy link
Owner

colinhacks commented Apr 23, 2024

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.

@kerrigan-nm
Copy link
Author

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.

@chrisjansky
Copy link

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.

@henriquealbert
Copy link

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.

Ayterx added a commit to Ayterx/server-action that referenced this issue May 1, 2024
@Ayterx
Copy link

Ayterx commented May 1, 2024

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

@lukebelbina
Copy link

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.

@catz
Copy link

catz commented May 7, 2024

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

@darbymanning
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants