What should the option be like? How about

{
  ignoreMethods: [{
    superClass: 'React.Component',
    method: 'render',
  }]
}

?

TBH the more I think about it the less I like it.
The checks to decide if a function should be ignored based on a filter are either very loose and far reaching (node.name === config.name), or they're complex to implement, and rather specific (like checking the function is a method and belonging to a class with superclass that is specifically React.Component - what about if someone import { Component } from 'react'?)

I don't think there's any good way to implement a "filter" config that works with the spirit of the rule (which is ensuring that every function has a defined return type).

The better way to implement this would be to add an option to enable "superclass" checks for class methods.
i.e. similar to the typed function check - ignore the function if there exists a function of the same name on the super class OR interface.
Because this check would use the resolved type of the class/interface, it wouldn't need configuration that's pretty unsafe.

How about an option like:

{ ignoreFunctionNames: ['render', 'componentDidMount', ...etc]}

Sure it is an overkill that affects much more functions than is intended. But it has the benefit that it is dead simple.

I mean I don't hugely understand why it's such a burden to write out the 5-6 characters that is : void - all of the react lifecycle methods in question return void (except render, which has many different possible return types, the most common of which is React.ReactNode).

Also the future of React is functional components, which need a type annotation anyways. So I don't hugely like the idea of adding an option purely to support an old way of doing things.

Like I said - I don't like having a whitelist of function names because it's indiscriminate of the context, and is also a pain to implement properly because you have to handle variable declarations, class methods, class properties, function declarations, arguments, etc. There's a lot of cases for such a simple option.

Hi @bradzacher, wanted to know if there's an update here. I think that usually it's a non issue but when having to type the complex type in mapStateToProps or mapDispatchToProps, things look ugly and more copy paste then wanted.

I'd appreciate you're opinion here.

Chiming in here. This was a request at my current company also. I was hoping it supported ignoredMethodNames like @typescript-eslint/explicit-member-accessibility does.

https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/explicit-member-accessibility.md

I have the exact same issue: I started using explicit-module-boundary-types which has a nice option allowedNames which does exactly this. However, later I realised it does not enforce signature types on private methods.

Therefore, I switched to rule explicit-function-return-type now realising that all methods are required a return type but above filter does not work. This adds unnecessary burden to type internal life cycle methods (StencilJS) or private render methods (they always return some form of VDOM or VDOM[]).

A allowedNames rule here would be very nice. Even better if that could be extended to support glob pattern, e.g. filter all methods/functions that start with "render" ("render*").

We currently use a patch for typescript-eslint that does the same for functions that start with "setup" ("setup*").

closing as explicit-function-return-type rule has now support for allowedNames https://typescript-eslint.io/rules/explicit-function-return-type/#allowednames