TypeScript: Subclass method is not allowed (TS2425) if the parent class has a property of type any with the same name

I don’t know who came up with this first, but TS and ESnext basically share the same critical mistake to consider a “class field”

class A {
    prop = 'abc';
}

equivalent to a constructor initializer

function A() {
    this.prop = 'abc';
}

instead of a default property on the prototype.

function A() {}
A.prototype.prop = 'abc';

Besides the fact that this is inconsistent with member functions (which are set on the prototype), this causes all kinds of nasty problems. For example, you can’t override a parent “class field” by setting a derived class prototype property.

class Base {
    prop = 'abc';
}

class Derived {}
Derived.prototype.prop = 'def';

const d = new Derived();
d.prop; // 'abc'

If “class fields” were prototype properties instead, there wouldn’t be any problem of this kind (below, I’m avoiding class field syntax in order to avoid confusion).

class Base {}
Base.prototype.prop = 'abc';

class Derived1 {}
Derived1.prototype.prop = 'def';

class Derived2() {
    constructor() {
        this.prop = 'ghi';
    }
}

(new Derived1()).prop; // 'def'
(new Derived2()).prop; // 'ghi'

I think that the current issue ticket is a symptom of this problem being reflected in the TS type system.

At first I thought that adding type checking to JS was a neat idea, but every time I ran into a problem like this (i.e., the TS type system being too incomplete to accurately reflect what’s going on in JS), I became more convinced that a dynamically typed language simply isn’t meant to have static type checking. Either you create a language that is actually statically typed and you can do all the type checking you want (cf. C++), or you create a dynamically typed language, enjoy the added flexibility and accept that you can only do runtime checks. Not to mention the lack of accurate typings for third-party libraries. Type checking isn’t going very well in Python, either.

I’m switching back to CoffeeScript, which has sane “class fields”. This is an important reason for me to switch back, perhaps even the most important.

The problem here is that prop(){} defined as method is placed on the prototype. prop: any as property is written directly to the instance (if it had an initializer) and thus overrides the prototype method. Consider the following slightly modified version of your code:

class Super {
    prop: any = undefined;
}

class Derived extends Super {
    prop() {}
}

new Derived().prop(); // runtime error: undefined is not a function

You can still use a function to initialize prop in Derived:

class Super {
    prop: any = undefined;
}

class Derived extends Super {
    prop = () => {}
}

new Derived().prop(); // works as expected

Some people mention that we can just use an arrow function, like

class Derived extends Super {
    prop = () => {}
}

but this is not ideal because

• it is wasteful to create one new function per instance, instead of sharing a single prototype function.
• it does not work with inheritance (we can not use super in an arrow function to call the same function of a super class).

@RyanCavanaugh It seems that a super class having an initializer is the main foot gun that the current restriction aims to prevent.

Can we perhaps have a way to allow overriding properties with prototype methods under the condition that the super class must not have an initializer for the property being overridden (and with strict types therefore requires it to be an optional property)?

For example, what if

class Super {
    prop?: boolean | (() => boolean)
}

class Derived extends Super {
    prop = true // ok
}

class Derived2 extends Super {
    prop() { return true } // ok
}

is valid with no type error, and

class Super {
    prop?: boolean | (() => boolean) = false // This has an initializer. It could also be in the constructor.
}

class Derived extends Super {
    prop = true // ok
}

class Derived2 extends Super {
    prop() { return true } // error
}

has a type error that says something like “The Super base class property prop has an initializer, therefore the subclass Derived2 can not override prop with a prototype method.”

I think allowing this under certain conditions would be great!

My specific situation is as follows:

// a library not originally written in TypeScript

class Super {
    prop() {  // meant to be overriden either with {} or () => {}
        return {};
    }
}

// somebody else's @types/library/index.d.ts

declare class Super {
    prop(): {};  // doesn't cover all cases
    prop: any;   // doesn't cover all cases either
}

// my code

class Derived extends Super {
    // If I want to override prop in a way not supported by the typings, I have a problem.
}

But it also applies if the library were written in TypeScript in the first place.

This does not mean “all syntactically-legal ES6 code must not have type errors”; see https://stackoverflow.com/questions/41750390/what-does-all-legal-javascript-is-legal-typescript-mean

Fair point. I started this ticket with different assumptions, so the opening post and the title probably don’t accurately reflect anymore what this issue is really about.

I’m not meaning to imply that TypeScript should just accept the example code I presented. Rather, the problem is that there seems to be no alternative. Semantically, it is a valid and even meaningful construction in JavaScript to override a base class method with a subclass non-function prototype property or vice versa. This is especially the case if the return type of the method is the same as the type of the non-function. To me, this seems like a scenario that could be type-checked, but again, there seems no way to do this in TypeScript.

If it hasn’t come up often, then apparently not many Backbone users work with TypeScript. In Backbone, _.result is used all over the place. You may be able to gain some ground there!

After all, it claims to be a superset!

This does not mean “all syntactically-legal ES6 code must not have type errors”; see https://stackoverflow.com/questions/41750390/what-does-all-legal-javascript-is-legal-typescript-mean

This has come up in the past but the specific scenario of “this method may be overriden by a property of a different type” hasn’t come up often enough to warrant a solution

What is Super doing here? Do you mean to have an interface instead?