Rule proposal: enforce polymorphic this types

[Zzzen]

For those who may have not heard it, here's the doc.

The main point is that if a function always returns this, it should be typed as this explicitly or have implicit this type.

Realworld example that breaks this rule:
https://github.com/BabylonJS/Babylon.js/blob/master/src/Meshes/transformNode.ts#L396

[armano2]

This rule should not be hard to implement (and should not require type checking)

To implement this rule we should check all codepaths returns from method and validate if they return this and do so only if rule already had return type.

[Zzzen]

It's easy to find all return statements of a method and then validate. But not all codepath returns, how do we check if all codepath returns? @armano2

[anikethsaha]

what's the status of this ? is anyone working in it?

[bradzacher]

Nope, but I suspect that this isn't quite as simple as described.

a this return type doesn't have to specifically be derived from return this, it could also be derived from a case like the following:

class Foo {
  returnsThis1(): this {
    return this;
  }
  returnsThis2(): this {
    return this.returnsThis1();
  }
}

So simple code-path analysis won't work here. It will require type information, and be a decent chunk more complex to implement.

---

As an aside - a good place to look for issues to work on would be this search which sorts issues by the number of reactions (a good metric for how "popular"/"needed" an issue is):
https://github.com/typescript-eslint/typescript-eslint/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22+sort%3Areactions-desc+

[anikethsaha]

class Foo {
returnsThis1(): this {
return this;
}
returnsThis2(): this {
return this.returnsThis1();
}
}

I actually planned to crawl the definition for the function in this case as a recursive as that function might be returning something else or this class's instances.
it did turn out to be a bit of complex.
I am thinking of reference tracker but not sure whether it would be compatible for ts !!

As an aside - a good place to look for issues to work on would be this search which sorts issues by the number of reactions (a good metric for how "popular"/"needed" an issue is):
https://github.com/typescript-eslint/typescript-eslint/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22+sort%3Areactions-desc+

on it 👍

[bradzacher]

The problem with crawling definitions is that you don't always have direct access to them - eg a method might exist on the parent.

This will require type information to assess.

[anikethsaha]

yea agreed 💯