`Maximum call stack size exceeded` error starting from 0.25.3

[ericmorand]

Search terms

Maximum call stack size exceeded

Expected Behavior

With 0.25.2 building the documentation of Twing was working perfectly. I expect that a patch release doesn't break something that was working.

Actual Behavior

Starting with 0.25.3 building the documentation of Twing fails with the error:

Maximum call stack size exceeded

Steps to reproduce the bug

I'm investigating the code of typedoc itself and the changes that were made between 0.25.2 and 0.25.3 and will update this issue as soon as I find the culprit.

In the meantime, here is the job log of Twing:

https://gitlab.com/nightlycommit/twing/-/jobs/5671446717

Environment

• Typedoc version: 0.25.3 and 0.25.4
• TypeScript version: 5.2.2
• Node.js version: 16.20.2
• OS: Ubuntu 20.04

[ericmorand]

OK, I narrowed it down to this reproductible test case:

type Foo =
    | FooA
    | FooB
;

interface BaseFoo<T extends string> {
    type: T;
    
    is<Type extends string>(type: Type): this is Foo & {
        type: Type;
    };
}

interface FooA extends BaseFoo<"A"> {
    
}

interface FooB extends BaseFoo<"B"> {

}

Using typedoc on this code will trigger the Maximum call stack size exceeded error.

[Gerrit0]

Wow, that's a weird one. That was a pretty small release in terms of changes.. Probably related to the mixin handling improvements introduced there.

[ericmorand]

The Typescript syntax that trigger the issue is quite unusual too - but valid - so it is understandable that it was never tested.

Probably something to do with the indirect circular reference, what do you think?

[Gerrit0]

Possibly, but the call stack in your logs tells me that somewhere typedoc is creating reflections with recursive parents, which should probably be like a 1 line fix. It's probably some copy paste mistake

[Gerrit0]

Ick. This is caused by the horribly hacky fix I put in for #2011... According to TS, Foo & { type: Type } is not an intersection.... which happens to conflict with the intersection check I put in to deal with some terrible mixin code, where we actually should be converting this as an intersection.

Feels like the compiler API ought to be admitting that this is an intersection though, I've asked in the compiler API section in Discord, hopefully one of the compiler devs will tell me I'm being dumb...

[Gerrit0]

Well, not completely dumb, but I'm surprised I hadn't realized before that if a type contains a union, the union must be present at the top level of the type, so TS is normalizing that type internally to be (FooA & { type: Type }) | (FooB & { type: Type })

The fix for this is to use the internal origin property to get the type before this transformation has been made.

[ericmorand]

Amazing. Thanks a lot.