Guys, please show your interest in #44997 (thumb up!) to resolve the issue faster

Currently, the limitation thresholds are hard-coded, to 50 and 5000000.

src/compiler/checker.ts

if (
  instantiationDepth === 50 ||
  instantiationCount >= 5000000
) {
  // We have reached 50 recursive type instantiations and there is a very high likelyhood we're dealing
  // with a combination of infinite generic types that perpetually generate new type identities. We stop
  // the recursion here by yielding the error type.
  error(
    currentNode,
    Diagnostics.Type_instantiation_is_excessively_deep_and_possibly_infinite
  );
  return errorType;
}

To make this configurable, I pushed a PR #44997, which makes those values be able to be set by compilerOptions that can be passed through CLI options or tsconfig.json, like an example below.

{
  "compilerOptions": {
    "instantiationDepthLimit": 100,
    "instantiationCountLimit": 10000000
  }
}

Though the PR is incomplete, just showing your interest would make its priority higher.

Thanks.

50 is really not that deep if you’re using fancy typescript inference… upping the limit could be pretty nice. I know TS Core in the past has been against inference but the TS community as a whole is using it more and more

Any updates on this issue?

I ran into this with xstate. The types work with 3.7.5 but upgrading to 3.8.2 gives error TS2589: Type instantiation is excessively deep and possibly infinite.

I made a quick gist to reproduce the issue, hope it helps: https://gist.github.com/qtiki/5f97233f609e516b5439e926514e85d9

Download the gist and run yarn and yarn tsc to get the error (or some npm commands if you prefer).

Hitting this issue. Using zod to merge several sub-schemas into a “complete” schema, resulting in the error. Hard-coding the resultant large schema works fine, but is more of a pain to maintain/less re-usable

I just added "strict": true to tsconfig.json and it solved

That does not solve it for me 😕

I had similar issue with zod, instead using z.merge or z.extend I used spread operators

export const addNewProspectSchema = z.object({
  ...generalSchema.shape,
  ...landSchema.shape,
  ...pvResourceSchema.shape,
  ...windResourceSchema.shape,
  ...productionSchema.shape,
  ...gridSchema.shape,
  ...
});

type AddNewProspectSchema = z.infer<typeof addNewProspectSchema>;

This solved the issue, at least for now. 😃

TypeScript team - is there any thought of putting in some syntax that could help guide the compiler during inference beyond a heuristic? For libraries that do schema translation this is going to be a continual headache. Perhaps something like a resolve keyword to tell the compiler to fully compute a type resolution, cache it and from then on treat the type as if it were declared by the user explicitly? Is the compiler already doing this as it’s resolving types?

// This is a fully resolved type that the compiler knows the user really really wants to happen so go nuts and cache it
type ResolvedType = resolve DeeplyRecursiveType<string, Person>

//This also gives a caching point for each type it is given;
type MySchemaMapper<T> = resolve DeeplyRecursiveType<string, T> 

//Using the above case this:
type MappedPerson = MySchemaMapper<string, Person> 

//is equivalent to this:
type MappedPerson = resolve DeeplyRecursiveType<string, Person> 

Intellisense could also benefit from this as a lot of mapped types end up being unreadable as they show complicated expansions. If the resolve keyword were used, intellisense could display the simplest form of the type declaration and not continue expanding when it encounters a “resolved type.” From my experience these deeply recursive types coincide with very generic API boundaries 90% of the time, so it’s a natural fit.

So what is the fix here. Nothing yet ? and we should not update to latest ts ? or refactor application code within limits ?

So to anyone who lands here and is getting this error in Node with express.

Our pipeline suddenly broke. No major code changes on our part… and it appears npm updated some packages

• Typescript went from 4.0.2 to 4.3.4 (i think)
• @types/node from 14.14.22 to 14.14.44
• @types/express from 4.17.11 to 4.17.12
• and a dependency of @types/express is @type/express-serve-static-core… which apparently when from 4.17.19 to 4.17.22

Running npx tsc was after these updates was causing the deep and infinite error. And very strangely… for instance:

const router = express.router();
router.get('/v3/app/userOpportunities/:userOpportunity_id/roadmaps', [...]); // <-- this was one of the error lines
export { router }

and even more odd… is that this STILL throws the error

...
router.get(':userOpportunity_id'); // still an error
...

and so I started playing around:

...
router.get(':userOpportunity'); // error
router.get('userOpportunity'); // no error (removed the semi colon)
router.get(':userOpp'); // no error changed word

having :userOpportunity anywhere in my route was throwing the error. but userOpportunity, :userOpp, something else etc would be fine.

I had three routes throwing errors… all of them were acting similar but with different words… 2 routes had :userOpportunity it and the third was complaining about :recommendationId

This made me think that the express types were being naughty. I started rolling things back slowly. Thus, I added @type/express-serve-static-core to my package.json (it was just a dependency) and forced it back to 4.17.21 and now the TS errors are gone.

On a side note… this only seems to fail in a unix environment for some reason.

UPDATE looks like the package will get fixed soon: https://github.com/DefinitelyTyped/DefinitelyTyped/commit/6973d2cc7f0ac4601f449273e2b0ff8790fdcf72#r52861403

What’s the likelihood of this issue getting addressed in the upcoming 4.2.0 release? Is someone actively working on this issue?

Same issue with styled components extending rmwc components:

import * as React from 'react'
import styled from 'styled-components'
import { Button } from '@rmwc/button'

const ButtonStyled = styled(Button)`
`

export function ConnectionSetting() {
  return <React.Fragment>
    <ButtonS />
  </React.Fragment>
}

We have the same issue in one of our larger projects. Works fine with 3.6.4 but not with 3.7.2

Using type keyof JSX.IntrinsicElements

in the meantime, one can use patch-package to create a per-project patch to implement the temporary fix:

1. edit node_modules/typescript/lib/tsc.js: search for 5000000 or instantiationCount and increate both the instantiationDepth and instantiationCount limits

2. run node_modules/.bin/patch-package typescript (via yarn patch-package typescript or npx patch-package typescript to generate the patch

should end up something like this in the patches/ folder:

diff --git a/node_modules/typescript/lib/tsc.js b/node_modules/typescript/lib/tsc.js
index 78c5ec2..7d6c586 100644
--- a/node_modules/typescript/lib/tsc.js
+++ b/node_modules/typescript/lib/tsc.js
@@ -49264,7 +49265,7 @@ var ts;
             if (!couldContainTypeVariables(type)) {
                 return type;
             }
-            if (instantiationDepth === 50 || instantiationCount >= 5000000) {
+            if (instantiationDepth === (50 * 2) || instantiationCount >= (5000000 * 2)) {
                 ts.tracing === null || ts.tracing === void 0 ? void 0 : ts.tracing.instant("checkTypes", "instantiateType_DepthLimit", { typeId: type.id, instantiationDepth: instantiationDepth, instantiationCount: instantiationCount });
                 error(currentNode, ts.Diagnostics.Type_instantiation_is_excessively_deep_and_possibly_infinite);
                 return errorType;

1. make sure to always apply the patch (e.g. after installation) by following patch-package’s docs for this purpose (also note this).

2. if using typescript project references, beware of hoisting of typescript itself - it didn’t work for me and resolved to some random package’s typescript install - do this in the root package.json (the nohoist):

{
	"name": "...",
	"workspaces": {
		"packages": [
			"...",
			"..."
		],
		"nohoist": [
			"typescript",
			"typescript/**"
		]
	},

Note: after some testing, it seems there’s no value that’s enough at least for my use case, even though it is not infinitely recursive…

P.S. If a project is using something like babel-loader through webpack (e.g. CRA), I do not know how to configure the tsc executable there or whatever other changes would be needed.

If someone finds this - please let me know.

in src/compiler/checker.ts on line 13208 (in v3.7.2) there is the following code:

function instantiateType(type: Type | undefined, mapper: TypeMapper | undefined): Type | undefined {
    if (!type || !mapper || mapper === identityMapper) {
        return type;
    }
    if (instantiationDepth === 50 || instantiationCount >= 5000000) {
        // We have reached 50 recursive type instantiations and there is a very high likelyhood we're dealing
        // with a combination of infinite generic types that perpetually generate new type identities. We stop
        // the recursion here by yielding the error type.
        error(currentNode, Diagnostics.Type_instantiation_is_excessively_deep_and_possibly_infinite);
        return errorType;
    }
    instantiationCount++;
    instantiationDepth++;
    const result = instantiateTypeWorker(type, mapper);
    instantiationDepth--;
    return result;
}

So the value is hard-coded. Perhaps a configuration option to change this might be warranted. As a workaround for now, you could try upping this limit and rebuilding the compiler.

Hitting this issue. Using zod to merge several sub-schemas into a “complete” schema, resulting in the error. Hard-coding the resultant large schema works fine, but is more of a pain to maintain/less re-usable

The same issue I have using zod, did you find any workarounds for it?

The depth fix mentioned in this article resolved my problem, even when sticking to an initial depth of 1 https://www.angularfix.com/2022/01/why-am-i-getting-instantiation-is.html

I would love to know why 😄

tsconfig

I hope to adjust the limit by tsconfig. How do you think?

This is definitely a problem for us, as we make an intensive use of type inference, and the type sometimes works and sometimes it produces this error, it’s not recursive, maybe simply too complex/deep. Also an indication about where (in the nested types) this error happens would be useful, as we cannot determine if it is really an error on our side or just TypeScript limitations

Here is a small snippet that causes the issue. It is recursive but not using React.

export declare type NoMethods<T> = Pick<T, Exclude<{
    [P in keyof T]: T[P] extends Function ? never : P;
}[keyof T], undefined>>;

export type PC<T, TChild=T> = {
    [K in keyof NoMethods<TChild>]-?: PC<T, Exclude<TChild[K], undefined>>
} & {get(): string}


function test<T>(values: PC<T, unknown>[]): string[] {
    return values.map(curr => curr.get()); //ERROR HERE
}

The strange thing is if I remove the map and change it to a forEach, this works fine. As in:

function test<T>(values: PC<T, unknown>[]): string[] {
    const results: string[] = [];
    values.forEach(curr => {
        results.push(curr.get());
    });
    return results;
}

has no errors.

I’ve noticed that strict mode fixes it. I just added "strict": true to tsconfig.json and it solved

| … 252 more … |

That’s a lot of properties ._.

One point in favor of upping the limit besides the weeks of my life wasted that I’ve spent battling these problems, is that I actually could easily speed up the tamagui types by 2x, except that it starts hitting complexity limits.

So in fact the complexity limit is making things slower in practice rather than faster.

Ran into the problem implementing a recursive mapper type:

export interface Route {
  path: string;
  label: string;
  icon: React.ReactElement;
}

export type Routes = Record<string, Route>;

export interface NestedRoute extends Route {
  children: NestedRoutes;
}

export type NestedRoutes = Record<string, NestedRoute>;

export type GetNestedRouteKey<R extends NestedRoutes> = {
  [key in keyof R]:
    | key
    | keyof R[key]['children']
    | GetNestedRouteKey<R[key]['children']>;
}[keyof R];

// * Example
type A = {
  ideas: {
    path: 'ideas';
    label: 'Discover';
    icon: ReactElement;
    children: {
      create: {
        path: 'create';
        label: 'Create';
        icon: ReactElement;
        children: {};
      };
      my: {
        path: 'my';
        label: 'My Ideas';
        icon: ReactElement;
        children: {
          published: {
            path: 'published';
            label: 'Published';
            icon: ReactElement;
            children: {};
          };
        };
      };
    };
  };
};
type B = GetNestedRouteKey<A>; // "ideas" | "create" | "my" | "published"

export type FlattenRoutes<R extends NestedRoutes> = Record<GetNestedRouteKey<R>, Route>; // Type instantiation is excessively deep and possibly infinite.

I have a similar issue with grommet-icons v4.4.0:

If I use the trash icon directly, all fine. If I wrap it with styled from styled component, I get the same message. No problem until typescript 3.5.2.

No Problem:

import { FormTrash } from 'grommet-icons';
export const AdProgramView = (props: PropType) => {
    return (
        <Container>
            <h3>
               {props.headline}
                <FormTrash onClick={deleteIntentCallback} />
            </h3>
        </Container>
    )
}

Problem with 3.7.2:

import { FormTrash } from 'grommet-icons';
const FormTrashStyled = styled(FormTrash)`
  vertical-align: bottom;
  cursor: pointer;
`
export const AdProgramView = (props: PropType) => {
    return (
        <Container>
            <h3>
               {props.headline}
                <FormTrashStyled onClick={deleteIntentCallback} />
            </h3>
        </Container>
    )
}

Same issue, using keyof JSX.IntrinsicElements type.

I get this issue right now but only in watch mode and only after file changes

I had similar issue with zod, instead using z.merge or z.extend I used spread operators

export const addNewProspectSchema = z.object({
  ...generalSchema.shape,
  ...landSchema.shape,
  ...pvResourceSchema.shape,
  ...windResourceSchema.shape,
  ...productionSchema.shape,
  ...gridSchema.shape,
  ...
});

type AddNewProspectSchema = z.infer<typeof addNewProspectSchema>;

This solved the issue, at least for now. 😃

Very nice!!

I have a similar problem.

I was using merge, pick and extend. After seeing your comment, I simplified the schema using the spread. However, the error continues to appear, probably the cause is now the pick method.

Any ideas on how to resolve it?

const getMonthlyInsuredItemSchema = monthlyInsuredItemSchema.pick({
  month: true,
  processedAt: true,
});

const getInsuredItemSchema = insuredItemSchema.pick({
  externalId: true,
  additionalAttributes: true,
  remainingInstallments: true,
  totalInstallments: true,
  installmentAmount: true,
});

const getInsuredPersonSchema = insuredPersonSchema.pick({
  name: true,
  cpf: true,
  birthdate: true,
  gender: true,
});

const getInsuredItemsResponse = z.array(
  z.object({
    ...getMonthlyInsuredItemSchema.shape,
    ...getInsuredItemSchema.shape,
    insuredPerson: getInsuredPersonSchema,
  }),
);

Update

The problem was in additionalAttributes .

I believe that what causes the error is the fact that the field is a jsonb in the database, receives a type transformation from drizzle-zod, and is then extended in another schema, generating many recurring type instantiations.

What I did was remove the additionalAttributes from the pick and redefine it explicitly in the getInsuredItemsResponse schema.

I’m getting it on the following snippet:

export class BaseConfig<T extends typeof BaseConfig> {
  public constructor(private readonly environment: Pick<InstanceType<T>, keyof T>) {
    // ...
  }
}

I was attempting to get the public props as constructor arguments type.

We have a similar issue with this code (roughly):

export type IconProps = TestProps & SizeProps & SpaceProps & DisplayProps & ColorProps<any>

// these are more than 450 props
export type ReactSvgProps = Omit<SVGProps<SVGSVGElement>, 'height' | 'width'>

export const createSvgIcon = (Component: FunctionComponent<ReactSvgProps>) => styled(Component)<IconProps>({display: 'inline-block', flex: '0 0 auto' }, compose(size, space, display, color))

// here we get the error
const MyIcon = createElement(Icon, { color: 'blue', marginRight: 'xs', marginLeft: '-xs'  })

Worth noting that if you’re upgrading from TS 3.5, something about how constraintDepth works was changed that can cause the max depth error, for code that was previously working fine (and nesting 100+ layers deep).

https://github.com/microsoft/TypeScript/issues/33541

I’m bringing this up because it looks like @dgieselaar is migrating from TS 3.5

I also have a todo on my personal project to investigate this, https://github.com/AnyhowStep/tsql/issues/25

But I’m not focusing on TS 3.7 support yet

There have been proposals made to increase the limit. They’ve been rejected because it’s seen as an “implementation detail” that should not be exposed.

PR: https://github.com/microsoft/TypeScript/pull/29602

Comment by @ahejlsberg

I’m very reluctant to expose the instantiation depth as a configurable parameter as it is an implementation detail that could change. Plus it is next to impossible to explain and reason about what value it should have.

https://github.com/microsoft/TypeScript/issues/29511#issuecomment-458620791

I agree with this part,

it is next to impossible to explain and reason about what value it should have.

If you’re writing library code, you should not be messing with this limit. If you’re writing application code and can force everyone on your team to use a hacked version of TS…

You can go ahead and hack the .js files for tsc and tsserver. Then, use https://www.npmjs.com/package/patch-package and commit the patch files