Mixing base class defeats circularity protection
#61,721 opened on 2025幎5æ18æ¥
Repository metrics
- Stars
- Â (48,455 stars)
- PR merge metrics
-  (å¹³åããŒãž 6d 17h) (30d ã§ 9 merged PRs)
説æ
ð Search Terms
mixin, referenced directly or indirectly in its own type annotation, recursively references itself as a base type, referenced directly or indirectly in its own base expression.
ð Version & Regression Information
- This changed in the PR #39675
Given that this was when base types were consistently checked for errors this has effectively existed forever, just only started being reported in #39675.
⯠Playground Link
ð» Code
declare class BaseCombatant {
constructor(...args: [Combatant["prop"]]);
// ^^^^^^^^^^^^^^^^^ 'args' is referenced directly or indirectly in its own type annotation.
}
declare class InternalClientDocument {
constructor(...args: any[]);
}
declare function ClientDocumentMixin<BaseClass>(
Base: BaseClass
): typeof InternalClientDocument & BaseClass;
// ^ Remove `typeof InternalClientDocument` and the circularity goes away.
declare class Combatant extends ClientDocumentMixin(BaseCombatant) {
// ^^^^^^^ Type 'Combatant' recursively references itself as a base type.
// ^^^^^^^ 'Combatant' is referenced directly or indirectly in its own base expression.
prop: number;
}
ð Actual behavior
Numerous errors.
ð Expected behavior
No error. This pattern is not intractable, in fact if you remove the useless typeof InternalClientDocument in typeof InternalClientDocument & BaseClass it works.
In reality I'm actually dealing with a useful mixin, not an empty class, so I would prefer this to work for a complete mixin as well. I'm guessing the issue has something to do with weaker caching around arbitrary expressions as the base class compared to the typical base class with a concrete name.
Additional information about the issue
No response