Inline *_base declaration in d.ts files

リンクされた TypeScript Playground の例と、issue に示されている宣言出力から始めてください。生成された d.ts ファイルで匿名クラスの基底がどのように表現されるかを調査し、その後、API-Extractor と recursive-type のユースケースがソースと整合したまま、基底がインライン化されていることを確認してください。

🔍 Search Terms

Anonymous class, _base, base, d.ts, api-extractor, recursive

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• 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:

class A extends class {} {}

Generates:

declare const A_base: {
    new (): {};
};
declare class A extends A_base {
}

playground link

My suggestion is for it to generate something like this instead:

declare class A extends ({} as {
    new (): {};
}) {
}

More generally replace:

declare const A_base: DEFINITION_OF_BASE_HERE;
declare class A extends A_base {
}

with:

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, 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. Sometimes this even ends up being compilation order dependent (similar to https://github.com/microsoft/TypeScript/issues/55758 ) and can result in failing incremental builds and working clean builds. 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 avoiding introducing additional such issues specific to the d.ts. 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.