feat: add suggestion for no-return-await

[dbartholomae]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[ ] Add something to the core
[X] Other, please explain:

Add suggestion to no-return-await, see #16632

What changes did you make? (Give an overview)

I've added a suggestion for removing await before return to the rule no-return-await and adapted the tests for all failing cases to ensure that the correct suggestion is generated.

Is there anything you'd like reviewers to focus on?

The change itself should be straight forward. I'm unsure if the createErrorList function I added in the test follows the code style used in this repo, though, and if it doesn't, am happy about suggestions how to do it differently.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: dbartholomae / name: Daniel Bartholomae (1cb6e4a, 60fe835)

[netlify]

✅ Deploy Preview for docs-eslint canceled.

Name	Link
🔨 Latest commit	6160c18
🔍 Latest deploy log	https://app.netlify.com/sites/docs-eslint/deploys/639c57a13843ef000891087a

[amareshsm]

Please sign EasyCLA (Contributor License Agreement).

[dbartholomae]

@amareshsm just did :)

[mdjermanovic]

We can safely fix the code if the argument is parenthesized and the opening parenthesis is on the same line as await.

For example:

async () => {
    return await (
        foo()
    )
};

In this example, however, node and node.argument do not start on the same line, so per the current condition the suggestion will not be provided.

We could do something like this:

const awaitToken = sourceCode.getFirstToken(node);
const tokenAfterAwait = sourceCode.getTokenAfter(awaitToken);
const areAwaitAndAwaitedExpressionOnTheSameLine = awaitToken.loc.start.line === tokenAfterAwait.loc.start.line;

(sourceCode is now needed in multiple places, so we could declare const sourceCode = context.getSourceCode(); in create(context)).

[dbartholomae]

I'm happy to implement this, though I would actually recommend not to do it, as it increases the complexity, risks of potentially introducing errors when running the suggestion if we missed a special case, and because suggestion from my point of view don't need to cover all use cases.
I'm a bit torn, though, as this might be a relevant case in a situation like the following:

async () => {
  return await (
    await fetch("https://really-long-domain.com/with-an-even-longer-path")
  ).json()
}

[mdjermanovic]

It's fine to implement this, it isn't overly complex and we have similar logic in other rules.

[dbartholomae]

It seems that getTokenAfter is not getting the token immediately after the note:

1. For async () => await bar(), it seems that sourceCode.getTokenAfter(awaitToken) is null.
2. For

   async function foo() {
     return await new Promise(resolve => {
       resolve(5);
     });
   }

   getTokenAfter gives the semicolon 2 lines after the await, which leads to missing a suggestion that could happen.

Instead, this worked:

const [awaitToken, tokenAfterAwait] = sourceCode.getTokens(node);

[mdjermanovic]

• For async () => await bar(), it seems that sourceCode.getTokenAfter(awaitToken) is null.

• For

  async function foo() {
    return await new Promise(resolve => {
      resolve(5);
    });
  }

  getTokenAfter gives the semicolon 2 lines after the await, which leads to missing a suggestion that could happen.

This looks like the result of sourceCode.getTokenAfter(node). Did you try this, it should work:

const awaitToken = sourceCode.getFirstToken(node);
const tokenAfterAwait = sourceCode.getTokenAfter(awaitToken);

[mdjermanovic]

Or this:

const [awaitToken, tokenAfterAwait] = sourceCode.getFirstTokens(node, 2);

[dbartholomae]

Thanks! Yes, I indeed tried to getTokenAfter(node) 🤦
Looking at the alternatives now, I actually feel like the current solution with getTokens reads cleanest and would keep it - what do you think?

[mdjermanovic]

sourceCode.getTokens(node) would go from the start till the end of the node to create and return an array with all tokens of the node, while we need only the first two. If you prefer a solution with getting all the tokens we need at once, sourceCode.getFirstTokens(node, 2) would be more optimal.

[dbartholomae]

Thanks, I'll change it right away

[dbartholomae]

Done

[mdjermanovic]

LGTM, thanks! I'll leave this open until today's release in case anyone else wants to review it before merging.

[dbartholomae]

Thanks, it was a pleasure! In case working with me wasn't too much of a hassle for you, and you have an issue that you would like me to work on, I can take one additional PR sometime around Christmas this year :)

[mdjermanovic]

Merged, thanks for contributing! You can always check issues labeled accepted.

For more details:

https://eslint.org/docs/latest/developer-guide/contributing/working-on-issues