Change @typescript-eslint/return-await to level error with 'always' config #41
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Here's the documentation for "always" setting. This change will affect our codebases largely, but fortunately it is auto-fixable. The change aims to improve two scenarios:
The community seems to be divided on the topic. Here's a few opposing opinions about why one should not use
return await
convention:no-return-await
rule eslint/eslint#12246 (comment)My personal take on this is that better stack traces overcomes the tradeoffs, assuming we are talking about backend node processes. This PR introduces the options only in node projects just to be safe. I checked that our frontend repo had only a single place where this config change fixed something, so enabling it there too wouldn't change much either.
Want to see the stack trace improvements in practice? Just save this
test.js
and runnode test.js
to see the effect.The result is that
return await bar()
has a better stack trace:For the curious, here's detailed explanation of why this happens in V8 nodejs/node#36126 (comment) and https://v8.dev/blog/fast-async