[explicit-function-return-type] Add option to ignore methods with specific names

[stasgavrylov]

Hi everyone, and thanks for all the great work on this plugin.

It would be nice if explicit-function-return-type would allow a way to set specific functions/methods to ignore for this check.
I don't think it makes a lot of sense to declare types on React lifecycle methods, like render or componentDidMount.
These methods probably shouldn't be ignored by eslint-plugin itself, but maybe it could provide an escape hatch for other plugins to use?

Right now the only 2 options available for this rule still do not allow to do this.

Thanks.

[golopot]

What should the option be like? How about

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

?

[bradzacher]

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.

[golopot]

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.

[bradzacher]

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.

[sonsina]

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.

[benjamincharity]

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

[pixelbucket-dev]

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*").

[neelance]

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

[armano2]

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