You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 3, 2021. It is now read-only.
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
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:
For more info: Click here
This line in particular seems to be enabling the rule:
tslint-config-leapfrog/tslint.json
Line 53 in 17c4728
The text was updated successfully, but these errors were encountered: