Repository navigation
Getting recursive type errors with TS 4.3.2 when they don't happen with TS 4.2.4 #44281
Description
Activity
It seems this was introduced in
4.3.0-dev.20210428(does not happen in4.3.0-dev.20210427).More specifically it seems to be introduced by the addition of this line
7748694#diff-d9ab6589e714c71e657f601cf30ff51dfc607fc98419bf72e04f6b0fa92cc4b8R17241
from a commit from Andrew Branch (@andrewbranch)
More specifically the call to getBaseTypes on this line seems to trigger some side effect that causes this:
7748694#diff-d9ab6589e714c71e657f601cf30ff51dfc607fc98419bf72e04f6b0fa92cc4b8R20008
The error seems to originate in getBaseConstructorTypeOfClass <- resolveBaseTypesOfClass <- getBaseTypes <- getSingleBaseForNonAugmentingSubtype
if (!pushTypeResolution(type, TypeSystemPropertyName.ResolvedBaseConstructorType)) { return errorType; }I don't think my knowledge is deep enough to dig any deeper :( but my super-wild guess is that the array related optimization in that commit is maybe trying to resolve the class structure earlier than before and therefore the cached versions cannot keep up with it
I think this is what's breaking my mobx-state-tree project when upgrading to TS 4.3. Not sure if this is affecting all MST projects or not but I ended up with a ton of recursive type errors after trying to update to TS 4.3.
Another example showing this bug is in #44284 (I've closed that issue in favour of this one). Just like this issue, it starts happening in 4.3.0-dev.20210428.
Another repro
abstract class Base { abstract root() : Derived } class Derived extends class extends Base { root() { return undefined as any } } { }
Unclear if this is working as intended, but it might be a regression.
Reacted by Javier Gonzalezhas it been decided already if it is a regression or maybe something else?
Not to pile on, but this has broken Zod pretty comprehensively. That said, Zod uses some pretty heinous recursive type hacks so I suppose I wouldn't be surprised if this is intentional.
Still happening with 4.3.3 when don't happen with 4.2.4. Playground
Error disappearing if remove
: A extends Uint8Array | Uint16Array | Uint32Array | Int8Array | Int16Array | Int32Array ? Array<number>
but compilation time is about 10x slower than 4.2.4.
The reproduction cases are still erroring for me after updating to 4.3.3...
Actually the merged fix code is not in TS4.3.3 at all...
- added a commit that references this issue
on Jul 22, 2021 Still happening with 4.4.1-rc.
Reacted by Alexis SécherAnders Hejlsberg (@ahejlsberg), the issue still happening with 4.4.2. Could you reopen the issue?
Reacted by Alexis SécherI think you might have better luck if you open a new issue with a playground link to the case that gets broken. as a matter of fact the two reproductions listed in the first post have been fixed in 4.4,so your issue might be because of another reason
Reacted by Daniel RosenwasserYeah something is still wrong in 4.4.2 but I'm not certain if it's this issue. My mobx-state-tree models blow up with thousands of errors if I try to upgrade, same as 4.3. I'm still stuck on 4.2.4 for now.
Would you each be able to open up a separate issue with a minimal repro? In the worst-case, we'll dedupe them.
Daniel Rosenwasser (@DanielRosenwasser), separated #45672
- locked as resolved and limited conversation to collaborators
on Oct 21, 2025
Bug Report
Given (this is just the smaller repro I could come up with, not real code):
With TS 4.3.2 it gives the errors:
where as there's no such error with TS 4.2.4
If the p function parameter is changed from
fn: () => Ttofn: () => anyorx: p<C[]>(() => [])is changed tox: p<C[]>(() => [] as any)then it does not give that error anymore.Real impact:
This impacts a library that used to be able to do self-referenced models:
but with the new version it is not possible anymore
Alternative repro:
🕗 Version & Regression Information
⏯ Playground Link
Playground Link