[explicit-function-return-type] add option to specify target of return type

[whatasoda]

Repro

I request to add option for explicit-function-return-type.
It is awesome rule, but I think it make a little redundant. What I want this rule at least is warning implicit any in return type.

{
  "rules": {
    "@typescript-eslint/explicit-function-return-type": ["error", {
      "target": "any"
    }]
  }
}

type SomeType = { ...... }
const someFunc = (): SomeType => { ...... };

const myFunc0_0_0 = (): any => Object.create(null);
const myFunc0_0_1 = () => Object.create(null);
const myFunc0_1_0 = (): SomeType => someFunc();
const myFunc0_1_1 = () => someFunc();

const myFunc1_0_0 = (): any[] => [Object.create(null)];
const myFunc1_0_1 = () => [Object.create(null)];
const myFunc1_1_0 = (): SomeType[] => [someFunc()];
const myFunc1_1_1 = () => [someFunc()];

const myFunc2_0_0 = async (): Promise<any> => Object.create(null);
const myFunc2_0_1 = async () => Object.create(null);
const myFunc2_1_0 = async (): Promise<SomeType> => someFunc();
const myFunc2_1_1 = async () => someFunc();

Expected Result
(Result what I want)
eslint warns only:

• myFunc0_0_1
• myFunc1_0_1
• myFunc2_0_1

Actual Result
(Current Result)
eslint warns only:

• myFunc0_0_1
• myFunc0_1_1
• myFunc1_0_1
• myFunc1_1_1
• myFunc2_0_1
• myFunc2_1_1

Additional Info
I'm not sure the option name target and value "any" are the best.
I'd like to discuss it.

Versions

package	version
@typescript-eslint/eslint-plugin	1.13.0
@typescript-eslint/parser	1.13.0
TypeScript	3.5.3
ESLint	6.1.0
node	10.15.3
npm	6.4.1

[bradzacher]

Why do you think this rule is redundant?
The rule is about creating explicit contracts for your functions to help ensure you're returning the correct values always.

Based on what you're asking for, it seems like you want to use our rule no-explicit-any.

[whatasoda]

The rule is about creating explicit contracts for your functions to help ensure you're returning the correct values always.

I understand the purpose of the rule, I also think we should ensure our functions to return the correct values.
But sometimes, like a function to use a third-party library with custom options, the return type is very clear and permanent, even if we don't specify it. But this rule warns it. Because of that, we should insert new lines to import third-party type or imitate and write third-party internal type.
That's why I feel it is redundant.

So, should I stop using the rule? No. I still have reason to use it.
The reason is to reduce unexpected any.

I want to use any if it is really any.
I want to know where unexpected any is, on IDE.
I want to see where every any is, on GitHub.

We can detect a change like types not any are added or removed from union types or intersection types. Because some warning occurs at lines using the value if there is something wrong.
But if the change includes any with something wrong, there may be no warning things and almost every type guards become disabled because it is any.
I think we can detect such a thing by using this rule, but it seems a little redundant for me as I said, and what I only want is about types related any.

My English may be unclear, please feel free to ask me detail. 🙏
Thank you.

[bradzacher]

I think I'm understanding you.

I want to use any if it is really any.

There isn't any case that it should be any. If you have an any, you have lazily typed and broken type safety!
You'll find that a lot of the rules are typed with any because unknown is only a recent addition, and changing from any to unknown in the core types would be a breaking change.

That shouldn't mean that you, as a consumer of the types, should just blindly use the anys, you should type them appropriately.

I want to know where unexpected any is, on IDE.

That belongs in a separate rule - I've opened #791.
This rule is specifically about explicitly typing the return type of your function.

[whatasoda]

Oh, I forgot about unknown 😇 . It seems I can replace any to unknown. Thank you!

That belongs in a separate rule - I've opened #791.

I read the issue. That solves my request more than expected 🚀.
Thanks a lot!!!