Remove `no-return-await` rule

What rule do you want to change?

no-return-await.

The rule description body of the rule not longer valid. The rule states that this syntax is useless although it is a very valuable implementation:

It has better performance than hand-written promises, and more importantly it produces better debugging stack traces.

Read full details about the benefits of using return await in this answer: https://stackoverflow.com/questions/44806135/why-no-return-await-vs-const-x-await/44806230#44806230

How will the change be implemented? (New option, new default behavior, etc.)?

I’d suggest removing the rule and introducing a new one that throws if a promise is not awaited inside an async function.

A saner approach is to update the rule description to reflect that this longer is no longer correct and deprecate it in code.

Please provide some example code that this change will affect:

return await <Promise>

What does the rule currently do for this code?

The rule states that this rule is useless although it is a very valuable implementation, it increases performance, produces better debugging stack traces, and it explicitly denotes that the returned function is a promise.

What will the rule do after it’s changed?

I’d vote for removing the rule and creating another one with the exact opposite behavior. IDK how you deal with backwards compatibility.

Are you willing to submit a pull request to implement this change?

No

[dbjorge]

I think the analysis of this rule in https://github.com/standard/standard/issues/1442 brings up a second, more important reason that would make me prefer to see this rule either deprecated or at least not-recommended-by-default, which is that it sets a trap for an assortment of different types of refactoring (see that issue for more details). Frankly, I think the refactoring traps are enough that I think it would make more sense for the default recommendation to encourage the await.

[dbjorge]

Further, I agree with the argument that the difference in stack trace usability and performance should be treated as an implementation detail, but I think that this should encourage picking the choice that leads to code which is easiest for a maintainer to understand regardless of whether some implementations might use an extra wrapping layer with the extra await, and I think making the sync/async nature more obvious to a reader has a bigger impact on improving readability than removing the redundant token does.

async function doThings() {
  const a = await thingA();
  const b = thingB(a);
  // This *looks* synchronous, but actually the reader can't tell without looking up function signatures.
  // The real behavior would be more obvious to a future maintainer with the await.
  return thingC(b);
}