A flag to make TypeScript more strict towards duck-typing classes

[noseratio]

Suggestion

🔍 Search Terms

JavaScript class, TypeScript interface, duck-typing, anonymous object

✅ Viability Checklist

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, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

I think it might be useful if TypeScript didn't always treat classes same as interfaces. For example, I'd like to see at least a warning when assigning a compatible anonymous object to a variable of a known class type, like this (Playground link):

class C { s: string = ""; }
const o: C = { s: "123" };
console.log(o.s);
console.log(o instanceof C); // false
console.log(o.constructor.name); // Object

📃 Motivating Example

The above code compiles without any warnings, which may come as a surprise for people coming from other OOP languages, and potentially cause runtime errors.

Unlike TypeScript interfaces, classes are still "first-class citizens" in JavaScript. I believe they're are essential part of JavaScript, and their value as types should rather be elevated by TypeScript, than diminished. This might help people coming to TypeScript from other languages (like C#, Java and even JavaScript itself!) who extensively have used classes before.

In this light, the author of that code fragment probably meant to write something that looks like below (Playground link). It'd be great if TypeScript introduced a CLI option to assist with spotting cases like that.

class C { s: string = ""; }
const o: C = Object.assign(new C(), { s: "123" });
console.log(o.s);
console.log(o instanceof C); // true
console.log(o.constructor.name); // C

On a side note, if I do this (Playground link):

class C { s: string = ""; }
const o: C = new C();
const o2: C = new o.constructor();
console.log(o2.constructor.name);

I don't understand the warning "This expression is not constructable. Type 'Function' has no construct signatures.(2351)" for the const o2: C = new o.constructor() line. It looks perfectly valid to me, the class type should be deductible in the above code fragment.

I can think of const o2: C = new (o.constructor as {new(): C})() as a workaround, or const o2: C = new (o.constructor as any)() as C. I don't like either, because at least the base class type for o is already known in this lexical scope, it's C.

💻 Use Cases

I hope I've covered that with the second code fragment, but also please see @Barbiero's comment below. Thanks for considering this idea.

[Barbiero]

This situation is a source of common mistakes for template return type, like angular's HttpClient methods. Ie.

class Foo {
  bar() { console.log('baz'); } 
} 

const result = await this.http.get<Foo>(url);

result.bar() // runtime error

This is because angular's library just parses the received object as a JSON, which is fine and a common behavior - but unaware developers(rookie ones especially, me included) might believe that result would have access to the class methods as if it was created with new and Object.assign like OP.

So I'm reiterating that a warning or error on trying to use class methods on an object that doesn't seem to have been constructed normally would be beneficial overall. Of course, as a strict-like flag to avoid mass breakage across the board.

[noseratio]

This situation is a source of common mistakes for template return type, like angular's HttpClient methods. Ie.

I happened to make this kind of mistakes exactly, when I just started with TypeScript coming with C# background. A warning or an error behind a CLI or tsconfig.json flag would be very helpful.

[noseratio]

@RyanCavanaugh, to provide a bit more feedback, one particular case is primitive types and their class type doubles. For example, a String:

let s1: String = "s1"; 
console.log(s1 instanceof String); // false
console.log(typeof s1); // "string"
console.log(s1.constructor === String) // "true"

Compare that to (Playground link):

let s2: String = new String("s2"); 
console.log(s2 instanceof String); // true
console.log(typeof s2); // "object"
console.log(s2.constructor === String) // "true"

Both compile and run without warnings but the only common output is true for s2.constructor === String. In my opinion:

• let s1: String = "s" - should compile with a warning, because it's ambiguous.
• let s1: String = new String("s") - all good, the author meant an object of String class
• let s2: string = "s" - all good, the author meant a primitive string variable

The same concern applies to interfaces:

interface IC {
    s: string;
}

class C implements IC {
    s: string;
    constructor(s: string) {
        this.s = s;
    }
}

• const c: C = new C("class") - all good
• const c: IC = new C("interface") - all good
• const c: IC = { s: "interface" } - all good
• const c: C = { s: "class or interface?" } - I'd expect a warning, because now c instanceof C is false.

[tarunama]

I don't understand the warning "This expression is not constructable. Type 'Function' has no construct signatures.(2351)" for the const o2: C = new o.constructor() line.

I have met this warning. So I don't understand above warning. Should be clear, If this suggestion is accepted.
In my opinion, absolutely agreement.

[noseratio]

I have met this warning. So I don't understand above warning. Should be clear, If this suggestion is accepted.
In my opinion, absolutely agreement.

I think this warning would make sense if the type of o in new o.constructor() was any or unknown. But that'd a be very rare case in TypeScript.

[noseratio]

Also, I don't think TypeScript should allow using implements to implement a class as interface, like below (Playground):

class C {
  methodC(): void {}
}

class C1 implements C { // bad
  methodC(): void {}
}

class C2 extends C { // good
  methodC(): void {}
}

console.log(new C1() instanceof C); // false
console.log(new C2() instanceof C); // true

I think implements should be limited to implementing interfaces, otherwise it may leave a false impression that multiple class inheritance is possible with TypeScript:

class C1 {
  methodC1(): void {}
}

class C2 {
  methodC2(): void {}
}

class C3 implements C1, C2 {
  methodC1(): void {}
  methodC2(): void {}
}

[tarunama]

I think implements should be limited to implementing interfaces

Strongly agree.

I think that it should be one way of class inheritance.
Now, class inheritance could be two way that use implements or extends.

This is curious.

[pjannesen]

This seems to be a core shortcoming of typescript.
In JavaScript, an object with (dynamic) properties is very similar to an instance of a class, but they are not the same. Some check's are added to make it better, such as checking private / protected properties / methods. But this is just a patch to work around the problem.

It would be better if typescript distinguishes between an type based of a typescript Interface description and type of a class

See also playground

[gh-andre]

Lack of being able to cast to a true class type, but otherwise behave as that type in assignments, etc, is indeed a major shortcoming and backfires in unexpected ways besides those mentioned above.

For example, this class-validator code will not fail because the object constructed has the type Object:

import { validate, IsInt } from "class-validator";

class A {
  @IsInt()
  a: number;
}

let x: A = {a: 123.45};

console.log(x.constructor.name);  // Object

// reports no errors because it's not an instance of A
validate(x)
  .then(val => {console.log(val);})
  .catch(err => {console.log(err);});

Using Object.assign fixes the validation, but now TypeScript assignment for object literal is broken and this reports no compilation errors:

let x: A = Object.assign(new A(), {a: 123.45, b: "ABC"});

The only way to work it around, it seems, is to have a function that produces the desired type via a construct signature:

function mkobj<T>(o: T, ctor: new (...arg: any) => T, ...arg: any): T
{
    return Object.assign(new ctor(...arg), o);
}

// properly reports the non-assignable error
let x: A = mkobj<A>({a: 123.45, b: "ABC"}, A);

A cast, including an implicit cast, should wire the target object just as the type suggests - the subject of a cast operation should be indistinguishable from an actual instance of a class, aside from levels of hierarchy, which may require some tweaking.

Being able to construct class instances from object literals, like it's done in C++, would make this problem less painful, but Microsoft closed that feature request a couple of years ago:

github.com/microsoft/TypeScript/issues/3895

[gh-andre]

I worked a bit more on casting objects to regain their original typing and wanted to post my findings, in case if somebody finds them useful.

I find that querying Mongo DB documents, which are structurally fully validated plain JavaScript objects, and using any form of copying, like with Object.assign in my post above, is just not a good way of doing it. Not only it initializes every data member twice, but what's worse, it requires that all data members would allow undefined for default constructing. A more logical approach is to set all prototypes throughout the entire plain JS object.

I'm aware that setting the prototype wipes out some engine optimizations behind the scenes, but in my case it works fast enough and doesn't require mutilated constructors. You may want to run a performance test for mission-critical modules, though.

In my actual code decorator factories are used to store object constructors in prototype's metadata using reflect-metadata. Interestingly enough, while working on this, I noticed that TypeScript is already half-way there and for non-union typed sub-objects stores constructors in design:type metadata (see example). Hopefully, this is an indication that TypeScript is heading this way. After all, TypeScript has all the types and using decorators for this and having to walk plain JavaScript objects searching for those types is an unthankful job that TypeScript should do - that's what compilers are for.

Just to be clear about what I mean, the effect of this approach is as if this code ran, except that sub-object types would be set via decorators and plain JS objects would be walked and their prototypes would be set from constructors stored in each parent's metadata.

function abc(target:any, name:string):void {}
class C {m: number = 123;}
class B {n: number = 456;}
class A extends B {
  x: number;
  y: string = "ABC";
  @abc  // a decorator is needed to show design:type
  c: C = new C();
  c2: Array<C> = [new C(), new C()];
  constructor (x: number)
  {
    super();
    this.x = x;
  }
  get my_x() {return this.x;}
}

// read from the database
let a: any = {n: 1, x: 2, y: "Y", c: {m: 3}, c2: [{m: 11}, {m: 22}]};

// a method, like cast<A>(A, a), walks the object and sets prototypes in real code
Object.setPrototypeOf(a, A.prototype);
Object.setPrototypeOf(a.c, C.prototype);
for(let e of a.c2) Object.setPrototypeOf(e, C.prototype);

// the object behaves as if it was new'ed
console.log(`is A: ${a instanceof A} x: ${a.my_x}`);    // true, 2
console.log(`is B: ${a instanceof B}`);                 // true
console.log(`is C: ${a.c instanceof C}`);               // true
console.log(`is C: ${a.c2[0] instanceof C}`);           // true

// set by TypeScript for members of a non-union type with a decorator
let ctor = Reflect.getOwnMetadata("design:type", A.prototype, "c");
console.log(ctor.name);                                 // C

Simple types, like C above, are quite easy to set up via decorators. Union types require some tweaking to indicate the discriminant property in the parent or in the child and a list of type identifiers and matching constructors. reflect-metadata's design:type is just set to Object for those, so there's no way to piggyback on TypeScript's built-in metadata for this.

[noseratio]

@gh-andre, very interesting, thanks. This might be worth a blog post on DEV.TO or like. I wasn't aware of JS decorators support by TypeScript. Gotta re-read the Handbook.

[kwasimensah]

Just ran into this. I think a workaround for now is to have at least one private function.

https://www.typescriptlang.org/play?noImplicitOverride=true&keyofStringsOnly=false#code/MYGwhgzhAEBiD29oG8BQ0PQA4FcBGIAlsNAE4CmYAJvAHYgCe0AHtALzQBEAZopwNzpMWUoQBuYAC7lovUsHIBhOhEmkcwSfFIAKAJQohGAL6pTqYCsmyADNABccROxTNHPPsf7QA9D+gAoqSk2tAATADsACwAjBZWsjEOTkgcyG5cvPCcADSy2grKtKrqmtqO+uwAfCjGXr7+QSGk4QDMYWHxxdbcYS605ADuKfqCqEA

class Foo {
    public readonly x = "foo";
    private forceConstructor() {
    }
}

const f0 : Foo = {x: "foo"}; // Error 2741 - Requires a forceContstructor property
const f1 : Foo = {x: "foo", forceConstructor: () => {}}; // Error 2322 - forceContstructor property is private and shouldn't be set external to class.
const f2 = new Foo(); // works