microsoft / microsoft/TypeScript

Mixin class with type param seems to lose information about default type parameter, causing "base constructors must all have the same return type"

Open
#56,005 0 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Bug Domain: classes Help Wanted
Dominant language
Go
Stars
111k
Forks
14.4k
Avg merge
1d 19h
Merged PRs (30d)
117

Description

🔎 Search Terms

Mixin class with type param seems to lose information about default type parameter, causing "base constructors must all have the same return type"

Related:
https://github.com/microsoft/TypeScript/issues/37142
https://github.com/microsoft/TypeScript/issues/40110

🕗 Version & Regression Information
  • This is the behavior in every version I tried, and I reviewed the FAQ for entries about mixins and type parameters
⏯ Playground Link

https://www.typescriptlang.org/play?ts=5.2.2#code/CYUwxgNghgTiAEAXAngBwQYQPYDsDOiMArmIljACpogA8FAfPALzxQBGBMUp8OIA7vAAUASmaMKAbgBQ0sLgLwAQrHYQQAMWbw6KvAhAAPRCBzA88bPkIkylajQDybAFbhE9ekL0gAXPAofMSZGAG9peEio9k5uRHhIKDwLFS42dRpU7U4ASxwAc0YjEzMUpIRwqKqotlghQ39cgrFQ+DhEIhgceENJeABfCOrB6raQDq7lVXSQGX6ZOWhkqeB4YtNzKbT1DSFnN1IWwcWkiwBxLCxV9dKttU0913cRGibC+FD+oA

💻 Code
declare type ConstructorType<T> = abstract new () => T;

const BarableF = <TBase extends ConstructorType<Object>>(Base: TBase) => {
      abstract class Barable<Bar = string> extends Base {
          bar(x: string) { return x; }
      }
      return Barable;
};

class Bad extends BarableF(Object) {}

class Good extends BarableF(Object)<string> {}
🙁 Actual behavior

The line class Bad extends BarableF(Object) {} fails because "Base constructors must all have the same return type". If I hover over BarableF, I see the type

const BarableF: <ObjectConstructor>(Base: ObjectConstructor) => ((abstract new <**Bar**>() => BarableF<ObjectConstructor>.Barable<Bar>) & {
    ...;
}) & ObjectConstructor

where notably Bar has lost its default type param, which might be causing the issue.

🙂 Expected behavior

I would expect Bad to type-check without a problem, because in the Good example below it, you see that providing a type argument that is the same as the default for the type param causes things to work.

Additional information about the issue

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked TypeScript Playground and reduce the Bad and Good examples to a regression case. Investigate generic mixin constructor inference and why Bar's default type parameter is lost; done means Bad type-checks without an explicit string argument while Good continues to work. Add the case to the relevant compiler test area once the behavior is localized.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
compilers
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.