“Type instantiation is excessively deep and possibly infinite” but only in a large codebase

[karol-majewski]

TypeScript Version: 3.7.2, 3.8.0-dev.20191102 (worked in 3.6)

Search Terms:

• Type instantiation is excessively deep and possibly infinite.ts(2589)
• Mapped types
• Generics
• Conditional types

Code

Note: this issue manifests itself only in our codebase. When you run the same code in TypeScript Playground, it seems to be working fine.

The snippet is hardly minimal, but I reduced it as much as I could. I recorded a video where exactly the same code yields an error different than the one in TypeScript Playground. I tried with two versions of TypeScript: 3.7.2 and 3.8.0-dev.20191102. It worked correctly with 3.6.

Since @sheetalkamat and @DanielRosenwasser have access to our repository, you're welcome to have a look at this PR. Copy-paste the code below anywhere in the project to see the error.

The versions of types used:

• @types/[email protected]
• @types/[email protected]
• @types/[email protected]
• @types/[email protected]

Note: Interestingly enough, if you change:

- declare const Button: React.FunctionComponent<Omit<Props, never>>;
+ declare const Button: React.FunctionComponent<Props>;

it works again despite the fact Omit<Props, never> should be the same as just Props.

Source code

import { History } from 'history'; // "4.7.3"
import * as React from 'react'; // "16.9.11"
import { LinkProps, RouteComponentProps, withRouter } from 'react-router-dom'; // "5.1.0"
import { getDisplayName } from 'recompose'; // "0.30.7"

declare function isDefined<T>(candidate: T | null | undefined): candidate is T;
declare function isString(value?: any): value is string;

type ObjectOmit<T extends K, K> = Omit<T, keyof K>;

type OnClick = NonNullable<React.ComponentProps<'button'>['onClick']>;

type OnClickProp = {
  /** If there is a custom click handler, we must preserve it. */
  onClick?: OnClick;
};

type ProvidedProps = OnClickProp;

type InputProps = OnClickProp & {
  /** Note: we want this helper to work with all sorts of modals, not just those backed by query
   * parameters (e.g. `/photo/:id/info`), which is why this must accept a full location instead of a
   * `Modal` type.
   * */
  to: Exclude<LinkProps['to'], Function>;
};

const buildClickHandler = ({
  to,
  onClick,
  history,
}: InputProps & {
  history: History;
}): OnClick => {
  const navigate = () => {
    // https://github.com/Microsoft/TypeScript/issues/14107
    isString(to) ? history.push(to) : history.push(to);
  };

  return event => {
    [onClick, navigate].filter(isDefined).forEach(callback => callback(event));
  };
};

/** See the test for an example of usage. */
export const enhance = <ComposedProps extends ProvidedProps>(
  ComposedComponent: React.ComponentType<ComposedProps>,
) => {
  type PassThroughComposedProps = ObjectOmit<ComposedProps, ProvidedProps>;
  type OwnProps = InputProps & RouteComponentProps<never> & PassThroughComposedProps;
  type Props = OwnProps;

  const displayName = `CreateModalLink(${getDisplayName(ComposedComponent)})`;

  const ModalLink: React.FunctionComponent<Props> = ({
    to,
    onClick,

    history,
    // We specify these just to omit them from rest props below
    location,
    match,
    staticContext,

    ...passThroughComposedProps
  }) => {
    const clickHandler = buildClickHandler({ to, onClick, history });

    const composedProps: ComposedProps = {
      // Note: this is technically unsafe, since the composed component may have props
      // with names matching the ones we're omitting.
      // https://github.com/microsoft/TypeScript/issues/28884#issuecomment-503540848
      ...((passThroughComposedProps as unknown) as PassThroughComposedProps),
      onClick: clickHandler,
    } as ComposedProps;

    return <ComposedComponent {...composedProps} />;
  };

  ModalLink.displayName = displayName;

  return withRouter(ModalLink);
};

type Props = React.ComponentPropsWithoutRef<'button'> &
  Required<Pick<React.ComponentPropsWithoutRef<'button'>, 'type'>>;

/**
 * This one errors.
 */
declare const Button: React.FunctionComponent<Omit<Props, never>>;

/**
 * This one works.
 */
// declare const Button: React.FunctionComponent<Props>;

const EnhancedButton = enhance(Button);

/**
 * Type instantiation is excessively deep and possibly infinite.ts(2589).
 */
() => <EnhancedButton></EnhancedButton>;

Expected behavior:

I should get a proper error about missing properties (not the one about type instantiation):

Type '{}' is missing the following properties from type 'Readonly<Pick<OwnProps, "form" | "style" | "title" | "onClick" | "to" | "key" | "autoFocus" | "disabled" | "formAction" | "formEncType" | "formMethod" | "formNoValidate" | "formTarget" | ... 252 more ... | "onTransitionEndCapture">>': to, type(2739)

Actual behavior:

I'm getting this:

Type instantiation is excessively deep and possibly infinite.ts(2589).

Playground Link:

Playground Link

Related Issues:

• #32735
• #34850

[AnyhowStep]

| ... 252 more ... |

That's a lot of properties ._.

[karol-majewski]

@AnyhowStep That's correct. The component in question mixes-in the props defined by JSX.IntrinsicElements['button']. There is a lot going on, and it is complicated, but it's a regression nonetheless because it worked in TypeScript 3.6.3.

[Stianhn]

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

[rista404]

Same issue, using keyof JSX.IntrinsicElements type.

[peterkelly]

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.

[AnyhowStep]

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

[karol-majewski]

@Stianhn @rista404 Have you managed to reproduce this issue using a more reduced example? If what we're dealing with is a valid use case, then understanding it could help us come up with a heuristic for when type instantiation limit should not be applied.

I agree that messing with the internals leads nowhere — after all, you need to draw the boundary somewhere.

As far as I know, this limit is not something new. It existed before, yet somehow this code stopped working. I wonder what changed that directly influenced our use cases.

[AnyhowStep]

git bisect? =x

[DanielRosenwasser]

Can you grant @weswigham permission to the repository as well?

[karol-majewski]

@DanielRosenwasser Yes! Invite sent @weswigham.

[dgieselaar]

Another example in https://github.com/elastic/kibana/pull/47188/checks?check_run_id=303150613 where @timroes is trying to upgrade TS to 3.7.2:

x-pack/legacy/plugins/apm/server/lib/metrics/by_agent/java/heap_memory/index.ts:58:10 - error TS2589: Type instantiation is excessively deep and possibly infinite.

  58   return fetchAndTransformMetrics({
              ~~~~~~~~~~~~~~~~~~~~~~~~~~
  59     setup,
    ~~~~~~~~~~
... 
  70     additionalFilters: [{ term: { [SERVICE_AGENT_NAME]: 'java' } }]
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  71   });

Related pull request: https://github.com/elastic/kibana/pull/47188

Related file: x-pack/legacy/plugins/apm/server/lib/metrics/fetch_and_transform_metrics.ts

edit: this issue will be fixed with the aforementioned pull request. We've added an explicit intermediary type (https://github.com/elastic/kibana/pull/47188/commits/ef912fc12ab95bca7b117a66cadabecc84d9a16a) that resolves the issue for 3.7.

[AnyhowStep]

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

[fabb]

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'  })

[macmillan78]

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>
    )
}

[aeon0]

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>
}

[sanketjo96]

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

[mkantz84]

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

[ds82]

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

That does not solve it for me :/

[qtiki]

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).

[vshlos]

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.

[moltar]

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.

[chicken-suop]

https://stackoverflow.com/questions/58311182/type-instantiation-is-excessively-deep-and-possibly-infinite-with-emotion-styled

[mateja176]

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.

[yonilerner]

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

[C0ZEN]

Got the issue with the latest discord.js release (12.3.0) and ts-auto-mock (2.3.4). More details on the ts-auto-mock issue.

[callionica]

I have isolated an example of hitting this error when trying to provide types for a function that deals with async iterables. Error is only hit when the function implementation is available and replacing the implementation with a declaration removes the problem even though the types have to be instantiated all the same.

The recursive type looks like this.

type ZipResult<T extends unknown[], Result extends unknown[] = []> = { 0: ZipResult<Tail<T>, Prepend<(InferIteratorValue<Head<T>> | undefined), Result>>, 1: Reverse<Result> }[Length<T> extends 0 ? 1 : 0];

The input array that instantiates this type is two elements long, so, perhaps naively, I would expect the recursion depth to be 6 (3 for recursion into ZipResult itself and 3 for recursion into Reverse). Nowhere near the limit of 50 mentioned earlier in the thread.

Code is available in the playground:

https://www.typescriptlang.org/play?target=6&jsx=0&ts=4.0.2#code/PQKhCgAIUgVALAlgZ0gYwPYBMCmlcC2GAdsgC4BOAhmTqlZAESwCeADnoqWVcWYjUQlIKSDgAeaOskQA3HABsW+HDjaReWSGwzIZAIyUjiAMy6JajMRQoYKxyLIAsAOgAMLgExQYPuPDwAcxxiHGpaLQApAGV0bDwKAFdSOJscNDIlFz8EPDJ2OkhkeAwAd2IHMgDIMgwMBX42VAU6gGtIAHkAaWzofzwSIzZbQxwCEVQqvDDbCl7fPoBJMkgCKmV9BMUaHC1ayESZYkCNCqpkFmI0SGDQ8LtIEwepkQI2BTGQnn4SAH5-vwAJTGGFkXBOL0Qbw+BC+gmEmkgFDUCioaHBIhWpQs8FOYgAjok5FQPnwVGhUeEhBUABQSKRsFZPewvEAASjECihXB2k2qMzsPh8wHA4HyHEgi1MYWWYRodgAaiTEjgADywAB8kAAvFBIPrYGJxLRiFhULLqKNVVwTGFIAq3Frfva3JAAFx6g1Gk1myW0e4Ua3S+wKgCMTvtofdnrg3pCvoAghcrhaqFabXaFZ4I1no-qvRIfagk5c0KnaoGMyGAMw56t5-OheQUADcovFeAAMiFAlV1XHTahkq1iGViABtAC6Wu1cHHAHJSb34PPJ22xQVIAAJHBULD9wvxofEEdjqcz2OHweQcfD0flAA0kBcL7vZ8nk8gztg47cn7dkBNmE64dnAVCIAoB7GkeBwnveE7TjqMbAMAKijgAtFyfDoYggSjsigEYOhEjvIg6JkOhvAsDGNI0i+LhkABsActqWpvuUHJXr6tGMacLBPvRPAQQBVYuixbFwWOHK-DGDoNvqQGtu2m4AArIhwpqqgAok+hpccep7lOeSH5pAtEBHuAE6c+L5UBQgTIEx4mwYZxCcdB160fRdkOSJwZiTqEmudJLrunAIGbsCzbIGqekeb67EIU+HQDglklGZ+s7GbOADeMZuABUVhDF6rgZBmpPmpajxqqO57uqGrJRqGoxqGAEdOAAC+47dscfaaqlqCus6UYAX+EUSgAWogbDAsgiQNFBRYufBU5PnNC0rPpK3vjqN6Ibl+UAdNs10JtpUQQ1lXqTVNJSraFDloqypqnV+6alqAA+sG4GYoRYGy61nQ0zUPq1hU4NFaobSDXU9T2-Vattw2QKNkDjaKKGQFpgKAh0gJMZuXDkLw-DwhUoj0tIciKMouBqKcWg6HoiCGMoNrmLQ4BY7gGFYRRuH4XgGEkVy5GUcQLDoQAIos0QJgAQp2WnS+A5ylo8yQZNSMAAF4zUtMGJeedEvhYcqjI5cBsgBJYpv6aYfKqJ0w2QDVanlpk8yERH8zheF2MLRGi2RFgS9RpkfCs5sBqgs4x47dAuGsbA0gnoyBWZ6cfBo9CS2y47RCwBD6PULjq-bcoVpONJsmybaRzg0dkHHZlUKU4ErGpGAECgODlwoChpw7FbIHXydUKnFiZzSOX4CQOAASYJIxU+CcViJKydXXDf5lHSJjOBxAYvHLcuEuVS7-qpRIDnNKUCqHKe6Ze9Nwf80NHtU5Xy-zJmfv08MAmExGPSAz8X4v0QMA4eLgsALyfjGCBEDkQfzIC4Nghx4A0mSL9Lgux66IKQZ1TkMUwGEKQa-FYaBEhpDJLOdundMQuHXnYFwoRjS1x-hQ0yUCzLUNoWguBoQEHcNEUwoReBZwPxwFwsRpl0LoWRGscwxxZGiM6uQ7hKDNroMwTSfhyI+AuFkC9AhciNEUIsUg3hNIlFH3BCIsR3s+ZcAFgHAiItxCkXFlRTRpkWCIEUFobRn9zh8TUZAYhihSHgK0U3GhxAIlWP1BojR3NULAneGiDEkJoSfD4OTSA2Iqg1CQKgXAFI7KFKUaCQoLwBQUHSRUykeATBax+BUfWbBDbXmNtOU25d7JW2YrbZMZYHZWhdsDN2H11z73EHtLpNJxyMCoIwJ8jB9DrKYGgRgk4nzjlDA+TwD5qyTgIeAIAA

[jevonearth]

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

[jevonearth]

It seems the issue for us is that type aliases are not lazily evaluated, and the compiler tries to expand all combinations until it can't.

To work around this, we introduced an empty interface in places, as it seems they are lazy. It's a bit of a kludge, and also a bit awkward because interfaces can't be used in unions.

Is there a better workaround/approach that we can take today, or a change in the compiler/language that might help us?

[akutruff]

I just hit this too when using 4.1's recursive conditional types. (Super amazing feature by the way.) It's hard to pair down to a simple example by the nature of this type of error. The below code allows someone to declare a TypeScript type. At the center of it all is Types which is a recursive conditional type. I had to remove constraints on UnionType<Types> to UnionType<unkown> Further, there's other places in the code where I should be able to add constraints to Types but I had to slowly remove them and add downcasts to prevent this error from showing up. Sorry, I know this is a lot of code, and doesn't repro with just the code below, but it is the level of complexity I'm dealing with. Using this code, it repros in the rest of my code.

export interface Type<T> {
    kind: T,
}

export const str: Type<'string'> = { kind: 'string', };
export const num: Type<'number'> = { kind: 'number', };
export const bool: Type<'boolean'> = { kind: 'boolean', };
export const bigint: Type<'bigint'> = { kind: 'bigint', };
export const nul: Type<'null'> = { kind: 'null', };
export const undef: Type<'undefined'> = { kind: 'undefined', };

export interface LiteralType<TLiteralValue> extends Type<'literal'> {
    kind: 'literal',
    literal: TLiteralValue
}

export interface ArrayType<TElement> extends Type<'array'> {
    kind: 'array',
    elementType: TElement
}

export interface UnionType<TMembers> extends Type<'union'> {
    kind: 'union',
    memberTypes: Array<TMembers>
}

export interface ObjType<TShapeDefinition> extends Type<'object'> {
    kind: 'object',
    shapeDefinition: TShapeDefinition;
}

export const literal = <T>(stringLiteral: StringLiteral<T>): LiteralType<T> => ({
    kind: 'literal',
    literal: stringLiteral,
});

export const array = <T extends Types>(element: T): ArrayType<T> => ({
    kind: 'array',
    elementType: element,
});

export function obj<TShapeDefinition extends IShapeDefinition>(shapeDefinition: TShapeDefinition): ObjType<TShapeDefinition> {
    return {
        kind: 'object',
        shapeDefinition
    };
}

export type OptionalType<T> = UnionType<T | typeof undef>;

//TODO: UnionType should be able to be UnionType<Types> but there is a depth hueristic that blows up.  
//    That means functions and types have to cast until it's fixed
//     https://github.com/microsoft/TypeScript/issues/34933
export type Types =
    Type<'string'> |
    Type<'number'> |
    Type<'boolean'> |
    Type<'bigint'> |
    Type<'null'> |
    Type<'undefined'> |
    LiteralType<unknown> |
    ArrayType<Types> |
    UnionType<Types> |  //Should be able to be UnionType<Types>, but has to be UnionType<unknown> to avoid this error!  
    ObjType<IShapeDefinition>;

export interface IShapeDefinition {
    [index: string]: Types
}

export type Shape<TDefinition> =
    TDefinition extends LiteralType<infer LiteralKind>
    ? LiteralKind
    : TDefinition extends Type<'string'>
    ? string
    : TDefinition extends Type<'number'>
    ? number
    : TDefinition extends Type<'boolean'>
    ? boolean
    : TDefinition extends Type<'bigint'>
    ? bigint
    : TDefinition extends Type<'null'>
    ? null
    : TDefinition extends Type<'undefined'>
    ? undefined
    : TDefinition extends ArrayType<infer ElementKind>
    ? Array<Shape<ElementKind>>
    : TDefinition extends UnionType<infer KeyKind>
    ? Shape<KeyKind>
    : TDefinition extends ObjType<infer TShapeDefinition>
    ? { [P in keyof TShapeDefinition]: Shape<TShapeDefinition[P]> }
    : never;

type ShapeDefinitionDistribute<TsType> =
    TsType extends StringLiteral<TsType>
    ? LiteralType<TsType>
    : TsType extends string
    ? Type<'string'>
    : TsType extends number
    ? Type<'number'>
    : TsType extends boolean
    ? Type<'boolean'>
    : TsType extends bigint
    ? Type<'bigint'>
    : TsType extends null
    ? Type<'null'>
    : TsType extends undefined
    ? Type<'undefined'>
    : TsType extends Array<infer TElementType>
    ? ArrayType<ShapeDefinition<TElementType>>
    : TsType extends object
    ? ObjType<{ [P in keyof TsType]: ShapeDefinition<TsType[P]> }>
    : never;

export type ShapeDefinition<TsType> =
    NotAUnion<TsType> extends never
    ? UnionType<ShapeDefinitionDistribute<TsType>>
    : ShapeDefinitionDistribute<TsType>;

//mad science: https://stackoverflow.com/questions/50639496/is-there-a-way-to-prevent-union-types-in-typescript 
export type NotAUnion<T, U = T> = U extends any ? [T] extends [boolean] ? T : [T] extends [U] ? T : never : never;

export type StringLiteral<T> = T extends `${string & T}` ? T : never;

export type FlattenedUnion<T> =
    T extends UnionType<infer K>
    ? FlattenedUnion<K>
    : T;

export type CollapseSingleMemberUnion<T> =
    NotAUnion<T> extends never
    ? UnionType<T>
    : T;

export const flattenMembers = <T extends Types[]>(members: T): Array<FlattenedUnion<T>> => {
    return {} as any as Array<FlattenedUnion<T>>;  //code removed for this example
};

export const union = <T extends Types[]>(members: T): CollapseSingleMemberUnion<FlattenedUnion<T>> => {
    const flat = flattenMembers(members);  //Blows up sometimes
    return {} as CollapseSingleMemberUnion<FlattenedUnion<T>>;  // edited for this example
};

const blowsUpSomeTypes = union([obj({name: str, age: num}), obj({isSomething: bool, anotherValue: num})]);

[andrei9669]

just hit this error when trying to make a generic interface for an api that uses only post request. that api has a ton of request variations. I guess that did the thing :/ I hit the limit after only 17 requests(51 if I include all possible request param combinations).