Rule proposal: typescript-eslint version of the base [require-await] rule

[scottohara]

Repro

Given the following config, it seems that there is an unresolvable conflict:

{
  "rules": {
    "require-await": "error",
    "no-return-await": "error",
    "@typescript-eslint/promise-function-async": "error"
  }
}

A function that returns a promise, such as:

function numberOne(): Promise<number> {
  return Promise.resolve(1);
}

..triggers @typescript-eslint/promise-function-async with the warning:

Functions that return promises must be async

Adding the async keyword:

async function numberOne(): Promise<number> {
  return Promise.resolve(1);
}

..then triggers require-await with the warning:

async function ’numberOne’ has no ‘await’ expression

Finally, adding the await keyword:

async function numberOne(): Promise<number> {
  return await Promise.resolve(1);
}

..then triggers no-return-await with the warning:

Redundant use of ‘await’ on a return value

Expected Result

No errors

Actual Result

(see repro above)

Additional Info

Individually, each of the configured rules address a legitimate problem. But together they appear to be mutually exclusive.

Over in ESlint core, there was a discussion on whether an async function that returns the result of another async function should be allowed to omit the await keyword without triggering require-await.

As @kaicataldo points out though, it isn’t really possible because ESLint is constrained by the limits of static analysis, and suggests that the help of a typing system (e.g Typescript) would be needed to implement this exception.

Hence I’m raising the issue here, to gather feedback on whether this implies the need for a @typescript-eslint/require-await version of the base rule.

Versions

package	version
@typescript-eslint/eslint-plugin	1.10.2
@typescript-eslint/parser	1.10.2
TypeScript	3.5.1
ESLint	5.16.0
node	12.1.0
npm	6.9.0

[bradzacher]

I've run into this problem myself! I got around it by turning off promise-function-async, mainly because I didn't like it.

It's always an option to extend a rule in here if it adds value. If we can make it better with type information, I don't see why not.