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

[jgonggrijp]

TypeScript appears to treat class methods as something fundamentally different from a class prototype property of type function. This is not in agreement with the standard semantics of ES6.

TypeScript Version: all versions, as far as I have been able to test.

Search Terms: method member property any parent class subclass

Code

class Super {
    prop: any;
}

class Derived extends Super {
    prop() {}
}

Expected behavior: should compile without a problem. Note that by the ES6 standard, the above definition of Derived is equivalent to the following, which TypeScript compiles without a problem:

class Derived extends Super {}

Derived.prototype.prop = function(){};

Actual behavior:

Error TS2425: Class 'Super' defines instance member property 'prop', but extended class 'Derived' defines it as instance member function.

Playground Link: https://www.typescriptlang.org/play/#src=class%20Super%20%7B%0D%0A%20%20%20%20prop%3A%20any%3B%0D%0A%7D%0D%0A%0D%0Aclass%20Derived%20extends%20Super%20%7B%0D%0A%20%20%20%20prop()%20%7B%7D%0D%0A%7D%0D%0A

Related Issues: I didn't find similar issues, although I started by looking for issues requesting for the ability to disable particular errors (TS2425 in this case). There are several (closed) issues in which such an ability is requested or suggested, but I believe the proper solution would be to bring TypeScript in agreement with ES6. After all, it claims to be a superset!

[ajafff]

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

[jgonggrijp]

Thanks @ajafff, I didn't think of that. The reason I'm running into this is not resolved yet, though. A common pattern in the JavaScript world is to allow an object property to either be of type A or a bound method of type () => A. Underscore's and Lodash's _.result is specifically meant to cater to this scenario. However, there seems to be no way in TypeScript to express such a typing:

// first attempt

class Super {
    prop: any;
}

class Derived extends Super {
    prop() {}
}

// problem as above

// second attempt

class Super {
    prop() { return {}; };
}

class Derived extends Super {
    prop = {};
}

// Property 'prop' in type 'Derived' is not assignable to the same property in base type 'Super'.
//    Type '{}' is not assingable to type '() => {}'.
//      Type '{}' provides no match for the signature '(): {}'.

There may be a way I'm not aware of (I hope there is), but otherwise, I'd argue TypeScript is missing something.

[RyanCavanaugh]

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

[jgonggrijp]

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.

[RyanCavanaugh]

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

[jgonggrijp]

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!

[pchodak]

Got the same when using :

class Super{
  test = function (){}
}

class Delivered extends Super {
  test() {}
}

[avonwyss]

For completeness (and people seeking help with TS2425 errors), you can always use type merging to "tell" TS that the member shall be seen as method.

The examples above for instance can be solved like this:

interface Super {
    test?(): void;
}

class Super{
  test = function (){} // test may also be undefined, it's optional on the interface
}

class Delivered extends Super {
  test() {}
}

[trusktr]

Unfortunately, that doesn't work well:

interface Super {
    test?: boolean | (() => boolean) // ERROR, All declarations of 'test' must have identical modifiers. (2687)
}

class Super {
  // I want this to be protected!
  protected test // ERROR, All declarations of 'test' must have identical modifiers. (2687)
}

class Delivered extends Super { // ERROR, Property 'test' is protected in type 'Delivered' but public in type 'Super'. (2415)
  protected test = true 
}

playground

This is a pattern I've seen in base classes before (in plain JS).

For example, here is a more representative example of what a base class may want to do (note the "ERROR 2425"):

import * as React from 'react' // this is only for JSX types, but we're not using React in the following example...

type Template = Element | (() => Element)

interface Super {
	template?: Template
}

class Super extends HTMLElement {
	// Subclasses can optionally provide a `template`, writing JSX to create a DOM tree.
	// BUT! Not all elements need to have their own Shadow DOM tree, so they don't have to define this.
	protected template

	connectedCallback() {
		const tmpl = this.template
		if (tmpl) this.render(typeof tmpl === 'function' ? tmpl : () => tmpl, this)
	}

	private render(template: () => Element, ctx: this) {
		this.attachShadow({ mode: 'open' })
		this.shadowRoot!.append(template.call(this))
	}
}


// This element has a simple static Shadow DOM, written with concise syntax.
class SomeElement extends Super {
	protected template = div(<div>This should work.</div>)
}

customElements.define('some-element', SomeElement)

// This element needs no inner Shadow DOM.
class OtherElement extends Super {
	connectedCallback() {
		super.connectedCallback()
		// ...does something special, without needing a `template`...
	}
}

customElements.define('other-element', OtherElement)


// This element make a local reactive variable (state) to render in its DOM. 
class AnotherElement extends Super {
	count = reactiveVar(0)

	protected template() { // <------- ERROR 2425 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
		setInterval(() => this.count.set(this.count.get() + 1), 1000)

		return div(<div>This should work too. The count is {this.count.get()}</div>) // updates the DOM every second.
	}
}

customElements.define('another-element', AnotherElement)

declare function reactiveVar<T>(initialValue: T): { get(): T; set(val: T): T }

// This is simple a no-op identity function, to type cast JSX.Element to a DOM type.
// See issues like
// https://github.com/microsoft/TypeScript/issues/14729
// https://github.com/microsoft/TypeScript/issues/31606
// https://github.com/microsoft/TypeScript/issues/35929
declare function div(j: JSX.Element): HTMLDivElement

Now strip all the type from that example, and you'll see that it is valid and well-functioning JavaScript.

[trusktr]

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!

[githoniel]

I have an example here

type Constructor<T> = new (...args: any[]) => T

interface Mergeable {
  merge: (
    obj: any,
    omit: string[]
  ) => void;
}

function Orderable<T extends Constructor<Mergeable>>(Class: T) {
  return class OrderableClass extends Class {
    merge(obj, omit: string[] = []) { // Error here 
      return super.merge(obj, [...omit, 'before', 'after'])
    }
  }
}

Error message is

Class 'Mergeable' defines instance member property 'merge', 
but extended class 'OrderableClass' defines it as instance 
member function.(TS2425)

I know the difference between class prototype function and class property. We could fix the error by

interface Mergeable {
  merge(
    obj: any,
    omit: string[]
  ): void
}

But in as in #18654 says they should behave different in strict mode.

A method and a function property of the same type behave differently. 
Methods are always bivariant in their argument, while function properties 
are contravariant in their argument under strictFunctionTypes.

How can I do this if I want to use function properties typechecking here with extend class override here?