Documentation of "no-return-await"

The version of ESLint you are using: 6.0.0 (but this is about the text on https://eslint.org/docs/rules/no-return-await — 1st paragraph there already)

The documentation of “no-return-await” was written without asynchronous stack traces in mind, which make using return await promise over return promise a vastly different experience — if you need to debug a rejected promise: With the await the calling function will be included in the stack trace (as of recent V8).

V8 recently introduced zero-cost async stack traces. Look for this term on https://v8.dev/blog/fast-async The example there with two functions foo()/bar() can be easily slightly modified to have a return await to convince yourself, if that is necessary, that what they write also applies when the await-ed promise is at the very end.

I think this changes the reasons given against return await, in the current documentation for the rule as well as on StackOverflow (but of course we can’t do anything about those) significantly. Anyone who ever had to debug a promise rejected by a sub-function called from different places, where seeing the parameters didn’t help knowing where it was called from (such as simply trying to load a file, if there is more than one place in the code that does that), knows that async. stack traces are a godsend, and getting them for free also during production and also on node.js and not just in Chrome dev. tools (with significant overhead) IMHO is reason enough to rethink the advice given thus far.

[ilyavolodin]

By purely for debugging I mean for getting information about the error. This does not have any positive effect (only unnoticeable negative effect) to the end consumer.

[kaicataldo]

Closing since the proposal author is no longer interested in pursuing this change.