Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Allow static members in abstract classes to reference type parameters

See original GitHub issue

Search Terms

abstract generic class static type parameter


It has been previously concluded in #24018 that referencing class type parameters in the static side is problematic unless that class is meant to be extended. Well, abstract classes are meant to be extended, so it makes sense to allow type parameters to be used?

To quote @andy-ms in #24018:

Without inheritance that wouldn’t make much sense:

class Super<T> {
    static m(x: T): void;
Super.m(); // What's `T`?

This is a valid point. But with a solution for abstract static members from #34516, this could be refactored like so:

abstract class Super<T> {
    abstract static m(x: T): void;

class A extends Super<number> {
    static m(x) {
        console.log(x * 42);

class B extends Super<string> {
    static m(x) {
        console.log(x + ' World!');


Use Cases

Pretty much everywhere that instance side types are related to static side types and where instance methods depend on static properties.


As an example I’ll give my personal use case. I have a class with a static defaults property and instances merge it with a constructor argument of the same type but partial. Then, the resulting object is stored in an instance property:

abstract class Base<T> {
    static defaults: T
    config: T

    constructor(options: Partial<T>) {
        this.config = Object.assign({}, (this.constructor as typeof Base).defaults, options);

interface Options {
    a: string
    b: number

class A extends Base<Options> {
  static defaults = {
      a: 42,    // Type '42' is not assignable to type 'string'.
      b: 'oops' // Type '"oops"' is not assignable to type 'number'.

let inst = new A({
    a: 'bar', // OK
    b: 'baz'  // Type '"baz"' is not assignable to type 'number'.

inst.config.a = 12; // Type '12' is not assignable to type 'string'.


My suggestion meets these guidelines:

  • 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, etc.)
  • This feature would agree with the rest of TypeScript’s Design Goals.

Issue Analytics

  • State:open
  • Created 4 years ago
  • Reactions:26
  • Comments:10 (2 by maintainers)

github_iconTop GitHub Comments

aleksrecommented, Sep 8, 2020

I would also love this feature to be added, but I don’t see why it should be limited to abstract members? As long as the super class is abstract, it should be sufficient. Consumption of inherited members is allowed through the non-abstract class.

In my use case I have a generic service for creating, updating, deleting and fetching resources through REST. This service is extended with specific services that modify the path used in the request (and also add their own requests), but TypeScript is unable to correctly type the response.

abstract class ResourceService<T> {
    protected static resourcePath = 'override-me'

    static async fetch(id: string) {
        const url = `api/${this.resourcePath}/${id}`
        return getRequest<T>(url) // 'Static members cannot reference class type parameters.'

class UserService extends ResourceService<User> {
    protected static resourcePath = 'users'

    // Additional functions specific to UserService

UserService.fetch('123') // GET api/users/123 -> Should be inferred as Promise<User>
legowerewolfcommented, Jan 19, 2020

I’d appreciate this. I’m running into this problem when I try to declare a type parameter for the shape of a config object for plugins in a plugin system I’ve created for a Discord bot project.

Right now, I have declared type any because different plugins (classes extending from an abstract Plugin class) use different config objects - they’re not standardized because different plugins do different things, so a universal interface wouldn’t be the right way to go. A type parameter would end up being used for the constructor’s config argument, the non-static config member, and the static defaultConfig member (used to define the minimum working config).

It would be great to get my linter off my back the right way by providing actual types instead of shutting it up with rule-ignore comments.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Flutter static members can't reference type parameters of the ...
Suppose you want something like: class Foo<T> { // ERROR: Static members can't reference type parameters of the class. static final ...
Read more >
Static abstract methods in interfaces - C# 11.0 draft ...
The members can be accessed off of type parameters that are constrained by the interface. Motivation. There is currently no way to abstract...
Read more >
Local and Nested Static Declarations - Oracle Help Center
Nested static declarations have no access to enclosing instances, local variables, or type parameters. This is addressed in the rules for references to ......
Read more >
Object orientation - The Apache Groovy programming language
Abstract classes represent generic concepts, thus, they cannot be instantiated, being created to be subclassed. Their members include fields/properties and ...
Read more >
Static fields should not be used in generic types
If you need to have a static field shared among instances with different generic arguments, define a non-generic base class to store your...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found