TypeScript: Version 3.4-dev breaks recursive types

I you run this on TS 3.4, you should see an error:

type Test00<T1 extends any[], T2 extends any[]> =
    Reverse<Cast<Reverse<T1>, any[]>, T2>

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

It happens when TS decides that types become too complex to compute (ie). The solution is to compute the types that cause problems step by step:

type Test01<T1 extends any[], T2 extends any[]> =
    Reverse<Reverse<T1> extends infer R ? Cast<R, any[]> : never, T2>

Can this error be disabled? I was unable to find it in the 3.4 breaking changes https://devblogs.microsoft.com/typescript/announcing-typescript-3-4/#breaking-changes

Update

This issue causes a lot of errors in the code base that we have at work. It is a large mono repo and we have a lot of recursive types. From example, we have types that map objects into immutable objects and we also have types to work with some data structures such as trees and graphs which are also recursive.

This is a breaking change, my project won’t compile 😐 Should this be reverted in 3.x and rereleased as 4.0?

@pirix-gh When we hit the instantiation depth limiter we force the type to terminate by resolving to an any. The only change in 3.4 is that we now report an error to let you know that we are delivering truncated (and unpredictable) results. Previously we’d just silently let it pass. So, I’m quite certain you were triggering the limiter before, it’s just that you weren’t hearing about it.

It’s entirely possible that I’m misunderstanding the above, but I can say with at least some confidence that, with TypeScript 3.3.3, many of my recursive types resolved to types that were very informative/helpful (not just to any), whereas, with TypeScript 3.4+, those exact same types now fail to resolve at all, and the “excessively deep and possibly infinite” error is reported. So, there appears to be more going on here than just error reporting.

Because of the above, I’d also appreciate this being regarded as a breaking change.

Maybe add posibility to customize “depth” of cheking by config option?

@pirix-gh When we hit the instantiation depth limiter we force the type to terminate by resolving to an any. The only change in 3.4 is that we now report an error to let you know that we are delivering truncated (and unpredictable) results. Previously we’d just silently let it pass. So, I’m quite certain you were triggering the limiter before, it’s just that you weren’t hearing about it.

@regevbr ts-toolbelt can solve your problem

I just rewrote getProp types based on what you’ve said.

import {O} from 'ts-toolbelt'

declare function getProp<O extends object, P extends string[]>(o: O, ...path: P): O.Path<O, P>

const o0 = {a: {b: {c: 'c'}}}
const o1 = {a: {b: {c: 100}}}

const t0 = getProp(o0, 'a', 'b', 'c') // string
const t1 = getProp(o1, 'a', 'b', 'c') // number

You can write much shorter types with ts-toolbelt, it computes for you.

I got the same error

export type SendFuncType<T> =
				T extends 1? FuctionType1:
				T extends 2? FuctionType2:
				T extends 3? FuctionType3:
				T extends 4? FuctionType4:
				T extends 5? FuctionType5:
				T extends 6? FuctionType6:
				T extends 7? FuctionType7:
				T extends 8? FuctionType8:
				T extends 9? FuctionType19:
				T extends 10? FuctionType10:
				T extends 11? FuctionType11:
				T extends 12? FuctionType12:
                                ...
                                T extends 73? FuctionType73:
                                undefine

The question mark expression about 73 lines, and it writen by tools. vscode give me the error: Type instantiation is excessively deep and possibly infinite.ts(2589)

Thanks @ahejlsberg for your quick reply. Understood.

But from another point of view. Since this is the only way (for now) to build (analysis) types for curry, and a lot of Ramda users are expecting them, can I still publish to DefinitelyTyped even if it does not pass the lint tests (exceptionally)?

How could we work this out @sandersn ?

I should add that there are two places where we may report that error. One is an instantiation depth of 50 (indicating a possibly infinite type), the other is a constraint depth of 50 (indicating a possibly infinite constraint).

I you run this on TS 3.4, you should see an error:

type Test00<T1 extends any[], T2 extends any[]> =
    Reverse<Cast<Reverse<T1>, any[]>, T2>

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

It happens when TS decides that types become too complex to compute (ie). The solution is to compute the types that cause problems step by step:

type Test01<T1 extends any[], T2 extends any[]> =
    Reverse<Reverse<T1> extends infer R ? Cast<R, any[]> : never, T2>

Hi! Thanks! You saved my day! 🙏

Closing issue, as this is clearly a #wontfix. If you need to create complex types, please use ts-toolbelt.

@regevbr thanks & sorry, I did not think about that one. Here’s something more suited:

import {O, A} from 'ts-toolbelt'

declare function getProp<O extends object, P extends string[]>(
    o: O,
    ...path: A.Cast<P, O.PathValid<O, P>>
    // `Cast` adds a constraint `PathValid` to `P`
): O.Path<O, P>

const o0 = {a: {b: {c: 'c'}}, b: {}}
const o1 = {a: {b: {c: 100}}}

const t0 = getProp(o1, 'a', 'b', 'c') // number
const t1 = getProp(o1, 'a', 'b', 'c') // number
const t2 = getProp(o1, 'a', 'b', 'x') // error
const t3 = getProp(o0, 'x', 'b', 'c') // error

Thanks, you gave birth to a brand new utility type!

And, remember to update to the latest release 😃

@pirix-gh that looks like a really cool library. But your solution doesn’t provide all I need.

For example the following returns type never, wheres my code will not even allow you to write it as it won’t compile.

import * as tb from 'ts-toolbelt';

declare function getProp<O extends object, P extends string[]>(o: O, ...path: P): tb.O.Path<O, P>;

const o0 = { a: { b: { c: 'c' } } };
const o1 = { a: { b: { c: 100 } } };

const t0 = getProp(o0, 'a', 'b', 'd'); // 'd' is not a valid propery

Also I also have getPropOr which returns a default value (or computes a default value from a given function for lazy evaluation of the default value). Is it possible to achieve it with toolbelt?

We don’t bump the major version for breaking changes (but thank you for thinking we’ve only ever had two breaking changes in six years of development! 😉)

That would be impressive. 😄But (if this was a reply to my latest comment) my hope was just that it would be regarded as a breaking change however it is that you regard things as breaking changes – e.g., by documenting it here.