[API Question] Is there a type resolution depth limit difference between compiling and running the language service?

[AnyhowStep]

TS 3.3.0-dev.20190103

I don't exactly have a minimal repro but I figured I'd ask my question first.

I'm experiencing a problem that I can only think is because TS is "giving up" on resolving the type in the IDE. But it resolves the type correctly during compile time.

IDE

I'm currently seeing this in my IDE,

And it seems to think that the following type, ReturnType<SelectDelegateT>[index] is any.

It also thinks that ReturnType<SelectDelegateT> is any.

However, when I just use SelectDelegateT, it gives me the full type, which is correct.

Compile-time

It was really weird because I was pretty sure I shouldn't get an error. I gave up on the IDE and decided to run tsc. I configured it to have noEmitOnError : true.

So, if there really is an error, it should spit out the same error as the IDE and not emit any types.

However, tsc ran fine. No errors.

I checked the emitted .d.ts file and the emitted type was resolved correctly.

---

So... Is my hunch right? Is there a "depth limit" difference between the language service that runs for the IDE (VS Code) vs the compiler?

And if so, is there a way for me to make it so that both have the same limit?
If possible, I'd like to make the limit as large as possible for both VS code and during compile-time.

[AnyhowStep]

The other weird thing is that part of my code looks like this,

{
    [index in Extract<keyof ReturnType<SelectDelegateT>, string>]: (
        ReturnType<SelectDelegateT>[index] extends IColumn ?
        (
            ReturnType<SelectDelegateT>[index] extends ColumnUtil.FromColumnRef<ColumnRefUtil.FromQueryJoins<QueryT>> ? never :
            ["Invalid IColumn", ReturnType<SelectDelegateT>[index]]
        ) : 
        never
    )
}

And the red squiggly line gives me ["Invalid IColumn", any]

Intuitively, to me,

If ReturnType<SelectDelegateT> really is being resolved to any, then Extract<keyof ReturnType<SelectDelegateT>, string> should be string.

ReturnType<SelectDelegateT>[index] would be any and so,

1. ReturnType<SelectDelegateT>[index] extends IColumn ? should be true
2. ReturnType<SelectDelegateT>[index] extends ColumnUtil.FromColumnRef<ColumnRefUtil.FromQueryJoins<QueryT>> ? should be true

And if the above two are true, then it should have been never and not ["Invalid IColumn", any]

---

The other weird thing is that I tried to shift some types around to change the error output and I get,

'{ [x: string]: ["Invalid IColumn", any, string]; }'.
    Index signature is missing in type '() => [Expr<{ readonly usedRef: { readonly merchant: { readonly appId: Column<{ tableAlias: "merchant"; name: "appId"; assertDelegate: AssertDelegate<bigint> & { __accepts: bigi/*snip*/

After the Index signature is missing in type ' part, it gives me the full type, resolved correctly. and not any! So, it is inferring the type of SelectDelegateT correctly, for sure.

But the fact that it thinks the type is '{ [x: string]: ["Invalid IColumn", any, string]; }'. means that it failed to resolve ReturnType<SelectDelegateT>[index] correctly =/

I'm so confused =(

[AnyhowStep]

Just updated to TS 3.3.0-dev.20190119

It seems like the type resolution depth limit is the same as the one in the language service now because even tsc is giving me errors.

Now I just gotta' figure out how to increase this limit =/

[AnyhowStep]

So, I just shifted some code around and it got rid of that any error ._.

Before:

export function isEnabled () {
    return o.and(
        t.merchantEnabledLog.latestValueOfEntity(
            c => c.enabled
        ),
        business.isEnabled(),
        appPlatform.isEnabled(),
        payOutMethod.isEnabled(),
    );
}

After:

export function isEnabled () {
    return o.and(
        o.and(
            t.merchantEnabledLog.latestValueOfEntity(
                c => c.enabled
            ),
            business.isEnabled(),
            appPlatform.isEnabled(),
        ),
        payOutMethod.isEnabled(),
    );
}

o.and() is a function that takes a tuple. It seems like splitting the tuples to lengths of 3, 2 instead of using a single tuple of length 4 helped. I don't know why it helped but it did.

The resultant type for both "Before" and "After" is the same.

[AnyhowStep]

I'm also having this weird problem where VS code highlights folders and files in red (to say they contain errors).

And when I open the files, VS code underlines some text with red squiggly lines, initially. Hovering over the lines gives me TS errors, all related to types not resolving properly (Becoming any).

But, after a few moments (seconds to minutes), VS code removes the red squiggly lines. I assume because it types checks successfully.

Closing the files makes VS code highlight those folders and files again after a few moments (seconds to minutes).

Makes me think that the depth limit is different for "background" vs "foreground" type checking. If that makes any sense at all.

[AnyhowStep]

I think I'm most definitely sure it has to do with some depth limit.

I have a bunch of calls to functions that are generics and rely on type inference.

declare function and</*Some Generic Type Params*/> (.../*Some Params*/) : /*Some Return Type*/;
function isEnabled1 () {
    return and(
        /*expr*/,
        /*expr*/
    )
}
function isEnabled2 () {
    return and(
        isEnabled1(),
        /*expr*/,
        /*expr*/,
        /*expr*/
    )
}
function isEnabled3 () {
    return and(
        isEnabled2(),
        /*expr*/,
        /*expr*/
    )
}
/*etc.*/

The return type of all these functions resolves fine on their own.

But when I start doing stuff like,

/*expr*/.select(() => [isEnabled3()])

And select() has types that use ReturnType<>, it all breaks down and resolves to any

[AnyhowStep]

I'm also having this problem where, on occasion, types are getting inferred as never and then the never types go away after a while.

But they always appear when I run tsc.

At this point, I'd be happy to mail my code to someone to look at what I'm doing wrong =/
I guess I'll try and get a minimal working repro this weekend or something.

[AnyhowStep]

I think it's got to do with some kind of iterative type resolution thing?

For example,

.where(canStartCreate)

1. Hover over canStartCreate, see an incorrect type resolution of type never.
2. Go to declaration of canStartCreate.
3. Start hovering over all expressions that make up canStartCreate.
4. Every time an incorrect type resolution is found, go to that declaration and hover over all sub expressions.
5. At the end, hover over canStartCreate again. It now has the correct type resolution.

I guess when I run tsc, it doesn't search deep enough and gives up and resolves to any or never.

@weswigham Sorry I'm tagging you directly but this is a little frustrating for me. I'm not too familiar with compiler internals, let alone tsc's but I was wondering if there is some kind of quick fix I could do on my end to bump the depth limit. Maybe change a constant in a file somewhere =/

[AnyhowStep]

I finally got it to compile successfully!

So, after a lot of random Ctrl+F > depth and searching through the code base, I finally found what I had to change,

I changed if (instantiationDepth === 50) { to if (instantiationDepth === 500) { in checker.ts and it compiled successfully in 123.49s.

Before the change, it failed in 71.92s.

Files:          3895
Lines:        130128
Nodes:        823248
Identifiers:  257678
Symbols:      702177
Types:        249365
Memory used: 569673K
I/O read:      0.52s
I/O write:     5.67s
Parse time:    9.24s
Bind time:     2.24s
Check time:   50.22s
Emit time:    61.79s
Total time:  123.49s

---

I ran into a lot of dead-ends trying to bump the flow depth limit, constraint depth limit, etc. But it seems like instantiationDepth was what I really needed.

---

I'm pretty happy with this because v2 of a library I worked on would take 180+s to compile.
Having a project use v3 and compiling in 123.49s is a pretty huge speed boost to me.

---

[EDIT]

Changed the limit to 250 and it still compiled successfully. Similar compile time as 500 (makes sense).

Files:          3895
Lines:        130128
Nodes:        823248
Identifiers:  257678
Symbols:      702177
Types:        249365
Memory used: 628652K
I/O read:      3.74s
I/O write:     1.51s
Parse time:   15.28s
Bind time:     2.30s
Check time:   49.50s
Emit time:    54.96s
Total time:  122.05s

I'm going to keep trying to decrease the limit until I get compile errors again.

[weswigham]

I'm pretty happy with this because v2 of a library I worked on would take 180+s to compile.
Having a project use v3 and compiling in 123.49s is a pretty huge speed boost to me.

😮 How many LoC is this project? 50s check time and 54s emit time is uuuge.

[AnyhowStep]

I've noticed that the instantiationDepth is hard-coded to 50 with the following comment,

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

Would be nice if we could make this configurable with a tsconfig.json.

---

I just noticed you asked me about LoC, I'll respond in a second :x
Need to look some things up.

[AnyhowStep]

Here's v3 of the library I'm working on. On npm, it's currently at version 1.13.1.

https://github.com/AnyhowStep/typed-orm/tree/v3

You can download the project and run npm run sanity-check and it'll recompile the library and run a bunch of tests on it.

It's an experiment in compile-time structurally-safe MySQL query building ;D

It takes about 40s to compile that library on my laptop.

---

That library doesn't suffer from this instantiation depth problem because I never wrote compile-time tests for nested MySQL expressions more than 2 or 3 levels deep.

---

However, in another project I'm working on (for work), it has MySQL expressions that are 5-6 levels deep, using the v3 library. So, I ran into this instantiation depth limit.

---

I think v3 of the library is about 50k LoC.

[AnyhowStep]

I think the emit time is really long because the generated types are really large. Not because I have many lines of code :x

For example, this is a compile-time test input file,

https://github.com/AnyhowStep/typed-orm/blob/v3/test/compile-time/input/query/select/from-table.ts

14 lines of code.

The output is here,

https://github.com/AnyhowStep/typed-orm/blob/v3/test/compile-time/expected-output/query/select/from-table.d.ts

81 lines of code.

---

[EDIT]

This project using the v3 library is currently at about 27k LoC, but only about 14k are using the library directly.

---

[EDIT]

Brought the limit down to 75 and it still compiles successfully!

Gonna' keep going lower.

---

[EDIT]

65 was too low and I exceeded the instantiation depth =(

[EDIT]

70 is still too low xD

[EDIT]

73 was still too low.
It compiled successfully with 74.

It seems like 74 is the lowest I can go at the moment before I get those errors again. I'm pretty sure I'll have to bump this higher in future when I start having more complex queries.

[AnyhowStep]

In addition to being able to configure the max instantiationDepth, it would be nice if an error message was added. Something like "Type resolution exceeded max instantiationDepth; consider simplifying the type or increasing the max instantiationDepth".

Then again, I'm not even sure how many people have realistically run into this problem to make this a worthwhile endeavor =(

[weswigham]

It came up once before when someone was nesting 200-some conditional types deep because they'd written what amounted to an else-if block of every syntax kind in TS. They just worked around the limit by reordering their type, though (so they had 200 top-level conditionals in a union instead of 200 levels of nesting).