"semantic error TS2589: Type instantiation is excessively deep and possibly infinite" with Zod 3.2

[nikhilag]

For a simple type such as:-

export const ZCustomer = z.object({
	name: ZString()
});

where ZString is:-
export const ZString = () => z.string().min(1)

I am getting a typescript error:-

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

I am using typescript 4.3.2 with Zod 3.2.0 in a tsdx 0.14.1 setup. Not sure what's wrong here.

[ingro]

Got the same problem on a relatively simple type:

z.object({
    name: z.string().nonempty(),
    city: z.string().min(3),
})

I'm using Zod 3.2.0 too but with an older Typescript version, 4.0.5.

[nikhilag]

@ingro Can you try with Typescript 4.1+? As mentioned in the documentation, Zod 3 requires TS 4.1+

[Goldweavers]

@nikhilag You're right, this is resolved by upgrading typescript.

[nikhilag]

Unfortunately it's happening in my case even with the latest typescript (see my message above). Do I need to downgrade typescript to an older version in case latest is not supported?

[colinhacks]

Having trouble replicating this @nikhilag, make sure your version of TypeScript is the one being used by VSCode. Otherwise try creating a replication repo.

[nikhilag]

Thanks for checking this @colinhacks
I was able to resolve the issue by moving to Zod 3.1 and Typescript 4.1.5.
I am not able to reproduce this issue in a smaller project. I am using Zod for all my types in a tsdx package where I am consistently hitting this issue with Zod 3.2 and I am not sure why. Spent a lot of time figuring this out but ultimately got lucky with trying a lower version of Zod. If at all possible, I can do a screen share and debug this issue with you.

[xargi]

Also running into this issue with Typecsript 4.3.2 and Zod 3.2. It occurs intermittently, which makes replicating likely difficult. Running tsc or jest twice in a row will throw the error one time and compile perfectly fine the next.

So far it seems to only occur on object schemas, even simple ones.

Maybe something to do with memory pressure?

[nikhilag]

The issue in my case was with tsdx. It seems tsdx was using an old version of typescript to build and hence I was running into that error. See jaredpalmer/tsdx#1044 for reference along with suggested fix.

[colinhacks]

@nikhilag Two other people just reported similar issues but I still can't reproduce it. I know it's been a while but do you think you could put together a reproduction repo?

[danalexilewis]

@colinhacks Having the same issue on a random z.object()

• Project uses Lerna/Yarn workspaces
• Upgraded TS to "typescript": "^4.4.2" in both the Workspace and all the packages
• Upgraded Zod to 3.8 in all 3 of the packages that used it.
• DELETED the lock-file
• rm -rf node_modules
• yarn install

And that seems to have resolved my errors.

[ghost]

I had a complex schema that was working fine and now I get this error from time to time.

OS: Ubuntu WSL 2
TS: 4.4.2
zod: 3.8.1

Tried removing node_modules and reinstalling, didn't help. Reduced schema to

var PostOffer = z.object({
  offer: z.object({}),
});

which helped for this yarn watch execution, but rerruning it broke it again.

4   offer: z.object({}),
           ~~~~~~~~~~~~
```.

I tried making repository that replicates my issue, but failed to.

[MarcelWaldvogel]

Just as an update for others running into the problem:

• Ubuntu 22.04 (OS typescript 4.5.4, project typescript 4.7.4)
• zod 3.17.10
• Yarn workspaces
• Medium-sized schema (70 LoC, nothing recursive, just three levels deep, but several z.discriminatedUnion()s)

After deriving a .deepPartial() from that, VScode started complaining about ts(2589).

rm -rf yarn.lock node_modules */node_modules; yarn fixed it; thanks to @agentlewis' advice.

(Restarting VScode before going rm -rf didn't fix it, so it must have been something persistent; I have no clue what on earth could be the reason for that behavior and why the reinstall fixed it. If it happens again, I will take a snapshot first and compare with the result after the reinstall.)

(Maybe the workspace from which the schema is imported had been compiled with the OS tsc (4.5.4) instead of the project tsc (4.7.4); but recompiling it with the old one did not make the problem resurface. Strange.)