Repository: TypeScript
Issue: Inline *_base declaration in d.ts files
Labels: Suggestion,Awaiting More Feedback

### 🔍 Search Terms

Anonymous class, _base, base, d.ts, api-extractor, recursive

### ✅ Viability Checklist

- [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
- [X] This wouldn't change the runtime behavior of existing JavaScript code
- [X] This could be implemented without emitting different JS based on the types of the expressions
- [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- [X] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- [X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

### ⭐ Suggestion

Currently classes which extends anonomous classes compile to d.ts files with two declarations:
```typescript
class A extends class {} {}
```
Generates:
```typescript
declare const A_base: {
    new (): {};
};
declare class A extends A_base {
}
```

[playground link](https://www.typescriptlang.org/play/?ssl=1&ssc=28&pln=1&pc=1#code/MYGwhgzhAECC0FMAeAXBA7AJjUkYG8BfaIoA)

My suggestion is for it to generate something like this instead:

```typescript
declare class A extends ({} as {
    new (): {};
}) {
}
```

More generally replace:
```typescript
declare const A_base: DEFINITION_OF_BASE_HERE;
declare class A extends A_base {
}
```

with:
 
```typescript
declare class A extends ({} as DEFINITION_OF_BASE_HERE) {
}
```

### 📃 Motivating Example

When exporting classes with anonymous bases (for example classes with bases generated using functions, for example in [fluid-framework's tree schema system](https://github.com/microsoft/FluidExamples/blob/16d0960cb38e9c1428cad12d01e1b71ec87a74f1/item-counter/src/schema.ts#L13), it would be nice if the generated d.ts file better matched the original source, so tools (like TypeScript and API-Extractor) behave more similarly to how they would if run on the source instead of on the d.ts. This would make the d.ts better serve as a concise summary of the type information of the original code.

### 💻 Use Cases

1. What do you want to use this for?
       I know of two cases this would help:
      1. API-Extractor: it would fix https://github.com/microsoft/rushstack/issues/4429 by removing this odd case from d.ts files.
      2. Some recursive types compile without error when the base in inline, but not when its split into a separate variable. Making the d.ts declare it inline when the original source files does helps make the d.ts more aligned with the non-d.ts type checking for recursive types. I haven't extracted a minimal repro for this, but there are some not so minimal examples (and a workaround) in https://github.com/microsoft/FluidFramework/pull/22122.

2. What shortcomings exist with current approaches?
Currently the behavior is confusing since most TS developers don't think about the differences between the d.ts files and the original source, so having to do workarounds to make them stay aligned (like manually exporting the base to make API-Extractor happy, or ensuring that if the base is not inline, that the code still type checked for the recursive case) is confusing and unintuitive.

3. What workarounds are you using in the meantime?
For API extractor, manually export the base type under a different name.
For the recursive type issue, export carefully crafted usage before the declaration which happens to cause it to compile with the split declaration.