Object.constructor isn't implemented specifically enough

Consider:

class Foo extends ([].constructor) {
}

[].constructor should be Array, which we aught to be able to extend. However, the checker complains on [].constructor that "Type 'Function' is not a constructor function type". Considering .constructor is quite explicitly the constructor function for the object, I believe this is a lie perpetuated by our lib.d.ts files. I think we need to go add appropriate self-constructor-referencing .constructor fields to each builtin.

Additionally consider the following:

class Bar {
}

class Foo extends ((new Bar()).constructor) {
}

The same thing but with a custom class rather than a builtin. We should know the correct type of .constructor here (the Bar class), but we don't - we just look at the members on Object.

In the first example, I believe it could be fixed with more precise lib files, but in the second case, I believe this is an instance of a field whose type should be known by the compiler, much like .prototype on the class itself is known.

Dupe of #4356?

Partially? The last bit where .constructor should be compiler inferred is a dupe of that, for sure.

But in the immediate future, we should fix our lib.d.ts files so that for builtins it is actually typed to the constructor function and not Function, as in the [].constructor example above.

Feel free to send a PR for this.

I'd like to share a workaround for when you need constructor property to have correct type. You can just specify the type using interface.

class Thing { }

interface Thing {
    constructor: typeof Thing;
}

let a = new Thing();
let b = new a.constructor(); // compiles just fine and the b has type Thing

You can even use it to fix the constructor property for external classes:

// -- file Thing.ts
export class Thing {

}


// -- file Second.ts
import { Thing } from './Thing';

declare module './Thing' {
    interface Thing {
        constructor: typeof Thing
    }
}

let a = new Thing();
let b = new a.constructor();

I think it's bit less hacky than previously suggested workaround:

class Thing {
    ['constructor']: typeof Thing;
}

that can in some circumstances produce following JavaScript code that sets constructor property to undefined:

class Thing {
    ['constructor'];
}

However my workaround is still not perfect because it doesn't work with inheritance if constructor parameters in base and derived classes don't match.

class A { 
    constructor() {}
}
interface A {
    constructor: typeof A;
}

class B extends A {                                     // error here
    constructor(x: number) { super(); }
}
interface B {                                            // and here
    constructor: typeof B;
}

One solution to this might be widening the interface of base class when some classes derive from it like so:

class A { 
    constructor() {}
}
interface A {
    constructor: typeof A | typeof B;
}

class B extends A {                                     
    constructor(x: number) { super(); }
}
interface B {                                            
    constructor: typeof B;
}

This expresses the actual state of things since once you start inheriting you can no longer be sure that instance you got in variable that has the type of base class actually is of that base class, not of one of the derived ones so you can't be sure what you actually got in constructor property.

This wouldn't be quite right, since we don't enforce static-side class assignability. An instance's .constructor is not necessarily the static constructor of its declared class. A value typed as Bar can be an instance of a derived class whose constructor has different required parameters; .constructor is also an inherited, mutable JavaScript property. Giving Bar instances the type typeof Bar for that property would therefore allow unsafe construction.

Navigation Menu

Repository navigation

Object.constructor isn't implemented specifically enough #4586

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Object.constructor isn't implemented specifically enough #4586

Description

Activity

kitsonk commented on Sep 1, 2015

weswigham commented on Sep 1, 2015

mhegazy commented on Sep 2, 2015

KamilSzot commented on Nov 2, 2022

RyanCavanaugh commented on Aug 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions