Skip to content
This repository was archived by the owner on Aug 3, 2021. It is now read-only.
This repository was archived by the owner on Aug 3, 2021. It is now read-only.

Allow return await statements #5

@exanup

Description

@exanup

Allowing return await [expression] is not an anti-pattern anymore.

TL;DR: Always do return await when returning a promise to benefit full error stacktrace. If a function returns a promise, that function must be declared as async function and explicitly await the promise before returning it

Otherwise: The function that returns a promise without awaiting won't appear in the stacktrace. Such missing frames would probably complicate the understanding of the flow that leads to the error, especially if the cause of the abnormal behavior is inside of the missing function

Snipped explanation:

There is a number of excellent articles explained why return await should never be used outside of try block and even an ESLint rule that disallows it. The reason for that is the fact that since async/await become available with transpilers in Node.js 0.10 (and got native support in Node.js 7.6) and until "zero-cost async stacktraces" was introduced in Node.js 10 and unflagged in Node.js 12, return await was absolutely equivalent to return for any code outside of try block. It may still be the same for some other ES engines. This is why resolving promises before returning them is the best practice for Node.js and not for the EcmaScript in general

For more info: Click here

This line in particular seems to be enabling the rule:

"no-return-await": true,

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions