Skip to content

Typescript has more trouble resolving circular class references when using mixins / through function invocations #55640

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
boconnell opened this issue Sep 5, 2023 · 0 comments
Labels
Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases
Milestone

Comments

@boconnell
Copy link

boconnell commented Sep 5, 2023

🔎 Search Terms

Mixin function invocation circular inherits references itself

Related issues:
#29872
#42383

🕗 Version & Regression Information

  • This is the behavior in every version I tried, and I reviewed the FAQ for entries about limit of typescript and resolving circular references.

⏯ Playground Link

https://www.typescriptlang.org/play?ts=5.2.2#code/C4TwDgpgBAwg9gOwM7AE4FcDGw6oCrgQA8eAfFALxQCGARiqtdlAhAO5QAUAdL9agHMkALhoIQAbQC6ASkrk8AbgCwAKDUAzdAmwBLRFAC21ANYQAsroAeuhCQBC1JNAhXgEBABMksRAyw4+IRE1OKkADRQAGK21AA28MhoAbiknGpQmUbWtlHaeoiinI7OonglEHIU5DEI8Yn+2LhqMkUVAPxlFVU1sQl+yU2oUADeGVmoEMDoqAhcHV1OlfKj41lZAPQbUJ5wUHDAABYQw0e2QlBsukdQFZFnPq7UhmBx0Lo+SLovcboauhBPGt1lBJtNZtkbAg8jpgPoEMUllB2u0uAB5WgAKwgzCcYhAMhkKlU6wAvsTSWo1JgBlBLFCopQjKYLDkEQ4ka53F4fA1BoECJAQmE0hVFs4eqsSTR6GgmMAoJg4k4fPTbFAuR5vLckWNpZkNHA4JxDXBRGqEABBMCvAGeSJcxiiWhGt6hVp0tnW22AqAAHygLrgbrmI1BUxmc0d1CglOlccyYMjnqhalJMip6lUNKSKdsACZGVRjGYLZwOc4NW4tbyBhghoLiKEQKRRUtxctqlLMnQGPLFcqkKq2fmq9ztRVu1laPwTUbzV6bb9AQ63E7A66IO6F1DvcvPP6N8Gt6Hw+Co2uYwnY+MkxCLfm0xms0qVXmrUu7WOa+-C5wLVEnCEqMpJAA

💻 Code

type ConstructorType<T> = abstract new (...args: any[]) => T;

function makeMixin<TBase extends ConstructorType<any>, FinalConstructor>(
    mixinFunction: (Base: TBase) => FinalConstructor
): (Base?: TBase) => FinalConstructor {
    return (Base?: TBase) => {
        // do other things with Base, this example is simplified
        return mixinFunction(Base ?? (Object as any));
    };
}

const MixinF = makeMixin(<TBase extends ConstructorType<any>>(Base: TBase) => {
  abstract class Mixin extends Base {
    foo(foo: MixinApplied, extra: boolean): MixinApplied | boolean { return extra }
  }
  return Mixin
})


const Mixin2F = makeMixin(<TBase extends ConstructorType<any>>(Base: TBase) => {
  abstract class Mixin2 extends Base {
    bar(foo: MixinApplied, extra: boolean): MixinApplied | boolean { return extra }
  }
  return Mixin2
})

class MixinApplied extends Mixin2F(MixinF()) {}

🙁 Actual behavior

The declaration for either Mixin1F or Mixin2F (unclear why it's not deterministic) errors with "'Mixin2F' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer." and the declaration for MixinApplied errors with "Type 'MixinApplied' recursively references itself as a base type.(2310)
'MixinApplied' is referenced directly or indirectly in its own base expression.(2506)"

I imagine I'm just running into some limits of the TypeScript compiler, but I can come up with at least 3 different scenarios that end with the same final result but without TypeScript errors, and this is preventing perfectly fine Javascript from being written. Mixins and function invocations seem to exacerbate the problem of recursive / circular references in class definitions.

For example, calling makeMixin within the function (instead of wrapping the function) and immediately invoking it works (TS playground):

type ConstructorType<T> = abstract new (...args: any[]) => T;

function makeMixin<TBase extends ConstructorType<any>, FinalConstructor>(
    mixinFunction: (Base: TBase) => FinalConstructor
): (Base?: TBase) => FinalConstructor {
    return (Base?: TBase) => {
        return mixinFunction(Base ?? (Object as any));
    };
}

const MixinF = <TBase extends ConstructorType<any>>(Base?: TBase) => {
  return makeMixin((Base: TBase) => {
    abstract class Mixin extends Base {
      foo(foo: MixinApplied, extra: boolean): MixinApplied | boolean { return extra }
    }
    return Mixin
  })(Base)
}


const Mixin2F = <TBase extends ConstructorType<any>>(Base?: TBase) => {
  return makeMixin((Base: TBase) => {
    abstract class Mixin2 extends Base {
      bar(foo: MixinApplied, extra: boolean): MixinApplied | boolean { return extra }
    }
    return Mixin2
  })(Base)
}

class MixinApplied extends Mixin2F(MixinF(Object)) {} // note: If I don't supply Object here, this fails for a different reason

const x = {} as MixinApplied;
x.foo(x, true);
x.bar(x, false);

Removing the makeMixin call also works (TS playground):

type ConstructorType<T> = abstract new (...args: any[]) => T;

const MixinF = <TBase extends ConstructorType<any>>(Base: TBase) => {
  abstract class Mixin extends Base {
    foo(foo: MixinApplied, extra: boolean): MixinApplied | boolean { return extra }
  }
  return Mixin
}


const Mixin2F = <TBase extends ConstructorType<any>>(Base: TBase) => {
  abstract class Mixin2 extends Base {
    bar(foo: MixinApplied, extra: boolean): MixinApplied | boolean { return extra }
  }
  return Mixin2
}

class MixinApplied extends Mixin2F(MixinF(Object)) {}

And of course the non-mixin version works as well (TS playground):

abstract class Mixin extends Object {
  foo(foo: MixinApplied, extra: boolean): MixinApplied | boolean { return extra }
}

abstract class Mixin2 extends Mixin {
  bar(foo: MixinApplied, extra: boolean): MixinApplied | boolean { return extra }
}

class MixinApplied extends Mixin2 {}

🙂 Expected behavior

It'd be great if the mixin + function invocation example worked as well as the others.

Additional information about the issue

No response

@RyanCavanaugh RyanCavanaugh added Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases labels Sep 13, 2023
@RyanCavanaugh RyanCavanaugh added this to the Backlog milestone Sep 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases
Projects
None yet
Development

No branches or pull requests

2 participants