Mixing base class defeats circularity protection
#61.721 geöffnet am 18. Mai 2025
Repository-Metriken
- Stars
- (48.455 Stars)
- PR-Merge-Metriken
- (Durchschn. Merge 6T 17h) (9 gemergte PRs in 30 T)
Beschreibung
🔎 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