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.

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

See original GitHub issue


🔍 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 instanceof C); // false
console.log(; // 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 instanceof C); // true
console.log(; // 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();

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.

Issue Analytics

  • State:open
  • Created 3 years ago
  • Reactions:18
  • Comments:12

github_iconTop GitHub Comments

Barbierocommented, Feb 9, 2021

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); // 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.

noseratiocommented, Feb 21, 2021

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 {}
Read more comments on GitHub >

github_iconTop Results From Across the Web

Grokking type conversion between TypeScript basic types ...
Edited: I've now filed a related issue in the TypeScript repo: A flag to make TypeScript more strict towards duck-typing classes.
Read more >
TypeScript Duck Typing, Want Strong Static Typing
I came up with one way to get stronger typing. I do not like it much. One adds a special field or method...
Read more >
Strict Types: Typescript, Flow, Javascript — to be or not to be?
We're at a crux where most advanced languages are moving towards functional programming or strict or static typing.
Read more >
If my grandma had wheels — Structural Typing in Typescript
Typescript offers balance between the power of a strict type system and the ease of use associate with more dynamic languages.
Read more >
Getting Strict With TypeScript - Better Programming
It will make a huge difference and will probably be the most time-consuming. If this flag is off , any type can be...
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 Hashnode Post

No results found