Repository: TypeScript
Issue: Compilation dependencies with mixins
Labels: Needs Investigation

# Bug Report
When using incremental compilation with typescript (3.x and 4.x), it seems that the compiler considers **any** change to a mixin class as requiring recompilation of all clients and subclasses of that class.
For non-mixin classes, it seems that the compiler does not force recompilation for clients and subclasses when a method body is changed or when a hard private (e.g. \#x: number) member is changed (added/removed/type changed) (it is unclear how dependencies are calculated for soft private members).

The cause seems to be, somehow, in the type inferred for the mixin function result, but this type should not depend on method bodies and privates.

### 🔎 Search Terms
<!--
  What search terms did you use when trying to find an existing bug report?
  List them here so people in the future can find this one more easily.
-->
incremental compilation
mixins
### 🕗 Version & Regression Information

<!-- When did you start seeing this bug occur?
Typescript 3.8 and onwards, not tested on earlier versions

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to
  https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

If possible, please try testing the nightly version of TS to see if it's already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly

Note: The TypeScript Playground can be used to try older versions of TypeScript.

Please keep and fill in the line that best applies:
-->
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about _________
- I was unable to test this on prior versions because _______

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link with relevant code](https://www.typescriptlang.org/dev/bug-workbench/?#code/PTAEAEDMEsBsFMB2BDAtvAXKAggWWgB7SIB0AKgMoCwAUAC4CeADvKAMID2iAznQE4BXAMZ0OfADxlQAXlAcARgCt4IgHwzQieAHdQAChKHkfAObcsyRAwDaAXQCUM9WQDctWvAJMxdUEK68OPhEiBqSAELI3KyedEgAJtzsAfzConyqepHRWGTZ8I7S6gDetKCgyPK8fMgifrBRSXiExKCxCUn5oKU05eVMfNAAbshxoJB69liIAqjy8HzdZX3lfPB0AnyhdAAW0NwkAMQEbr19AL7L-XwccSLw8aAmk9Oz84s9K6vrm6EADKcVpczuUdi9NG8FksQX01hstqAAVdQMCVsdXnMobIkTCBsNRqwGBj3hocSsBrcVHFHgAvYlYxGAvraemLbFM1GgOG-IItRCnc6nDxeHygRgsHBWABiAkQImgXHE2A0lgY6lkBkMxCYAjoFisdkK6mwp083j4vnFrGCxEkbQIcUQiUlDBlcroCsQ6tAAEkeHRLEJ4GRmPBxAAlH5bEMsSSqVRCmhm0VW0BkG2hWQZ8RWjiQXkhBPuGggCAwBAodBYNgNbgHSjC82+IS1pI1xrQ674sYTKYQzEfZHchG7fZHE7LTkUu7Up7gmYDzuwqP-DnLMF9hckz7L+GryfLdH995MvEjMZE48LU83GcPUB0q98Jksp8C4u0UtQOBINCYUAUAI8jtnW5DUDQ0CoE23TsK2KLjDcqCgAARCQwAgdwyGnJB0HFAWrTnAhHBIahwDNCEWHFsmFr1B2GaAfILYdu0TpNBmegAPJKFSjjFMC1HNnBGEMUxdb2o6zoYd0wKfmA34Vn+1awNASB0GBtA4aKeHpny8GQIhKFoeRxCURBUFabBHaEfpxGGehramY2oqiW2ymqUuBC5BmTKXhh740LQQA)

### 💻 Code
In the code below, we have 4 files:
Mixin is a basic mixin
Class is a similar class,
Client is a client that uses both Mixin and Class
Subclass is a file with subclasses for Mixin and Class

<!-- Please post the relevant code sample here as well-->
```ts
//File: Mixin.ts

type Constructor<T = object> = new (...args: any[]) => T;

export const Mixin = <TBase extends Constructor>(Base: TBase) => {
  abstract class Mixin extends Base {
    private f(): number {...}
    protected g(): number {...}
    h(): number {...}
    #x: number;
    private y: number;
    protected z: number;
    w: number;
  }
  return Mixin;
};

type AnyFunction<A = any> = (...input: any[]) => A;
type Mixin<T extends AnyFunction> = InstanceType<ReturnType<T>>

export type TMixin = Mixin<typeof TMixin>;


//File Class:
export class Class {
  private f(): number {...}
  protected g(): number {...}
  h(): number {...}
  #x: number;
  private y: number;
  protected z: number;
  w: number;
}

//File Subclass:
class MixinSubclass extends Mixin(Object) {}
class ClassSubclass extends Class {}

//File Client:
class Client {
  x: TMixin;
  y: Class;
}

//(we did not include import statements)
// We can quickly address your report if:
//  - The code sample is short. Nearly all TypeScript bugs can be demonstrated in 20-30 lines of code!
//  - It doesn't use external libraries. These are often issues with the type definitions rather than TypeScript bugs.
//  - The incorrectness of the behavior is readily apparent from reading the sample.
// Reports are slower to investigate if:
//  - We have to pare too much extraneous code.
//  - We have to clone a large repo and validate that the problem isn't elsewhere.
//  - The sample is confusing or doesn't clearly demonstrate what's wrong.
```

### 🙁 Actual behavior
<!-- What happened, and why it was wrong -->
We have observed that **any** change to Mixin - that is, to Mixin.#x|y|z|w and even the bodies of f(),g(),h() causes recompilation of both Client.ts and Subclass.ts, 
If we modify Class.#x|y|f() we do not observe recompilation of Client.ts or Subclass.ts, and if we modify Class.z|g() we do not observe recompilation of Client.ts, as expected.
In addition modifying method bodies in Class do not cause any recompilation, and as well adding more imports or non-exported declarations

### 🙂 Expected behavior
<!-- What you expected to happen instead, and why -->
For Mixin, we would expect that only changing h() and w will recompile Client.ts and in addition changing g() and z will recompile Subclass.ts, we also expect that modifying any of the method bodies including h() and g(), will not recompile any other file, unless the body is used to infer the return type of the method (and then only if the return type actually changed).