require-await

Disallow async functions which have no await expression

Asynchronous functions in JavaScript behave differently than other functions in two important ways:

The return value is always a Promise.
You can use the await operator inside of them.

The primary reason to use asynchronous functions is typically to use the await operator, such as this:

async function fetchData(processDataItem) {
    const response = await fetch(DATA_URL);
    const data = await response.json();

    return data.map(processDataItem);
}
1
2
3
4
5
6

Asynchronous functions that don’t use await might not need to be asynchronous functions and could be the unintentional result of refactoring.

Note: this rule ignores async generator functions. This is because generators yield rather than return a value and async generators might yield all the values of another async generator without ever actually needing to use await.

Rule Details

This rule warns async functions which have no await expression.

Examples of incorrect code for this rule:

Open in Playground

/*eslint require-await: "error"*/

async function foo() {
    doSomething();
}

bar(async () => {
    doSomething();
});
1
2
3
4
5
6
7
8
9

Examples of correct code for this rule:

Open in Playground

/*eslint require-await: "error"*/

async function foo() {
    await doSomething();
}

bar(async () => {
    await doSomething();
});

function baz() {
    doSomething();
}

bar(() => {
    doSomething();
});

// Allow empty functions.
async function noop() {}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

When Not To Use It

Asynchronous functions are designed to work with promises such that throwing an error will cause a promise’s rejection handler (such as catch()) to be called. For example:

async function fail() {
    throw new Error("Failure!");
}

fail().catch(error => {
    console.log(error.message);
});
1
2
3
4
5
6
7

In this case, the fail() function throws an error that is intended to be caught by the catch() handler assigned later. Converting the fail() function into a synchronous function would require the call to fail() to be refactored to use a try-catch statement instead of a promise.

If you are throwing an error inside of an asynchronous function for this purpose, then you may want to disable this rule.

Version

This rule was introduced in ESLint v3.11.0.

Resources

Edit this page