-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docs: improve documentation of no-return-await #13215
Conversation
Co-Authored-By: Kai Cataldo <kai@kaicataldo.com>
Co-Authored-By: Kai Cataldo <kai@kaicataldo.com>
Thanks @kaicataldo! I incorporated both of your changes. Let me know if you want me to squash this |
@kaicataldo anything else I can do to move this forward? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay! I have a few suggestions around organization/wording, but this generally LGTM and I think outlines the trade offs well. Thanks for working on this!
Co-authored-by: Kai Cataldo <kai@kaicataldo.com>
@kaicataldo No worries, great suggestions! I've committed them ✔️ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you!
Awesome, thanks for the merge! 👏 |
this is a resubmit of eslint/archive-website#716 but to the correct repo☺️
Prerequisites checklist
What is the purpose of this pull request? (put an "X" next to an item)
[x] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:
What changes did you make? (Give an overview)
First of all, I know that there have been a lot of discussions on wether this rule is a good one or not. I do not want to bring up that discussion here at all. I just want to clarify the documentation to better explain the implications, I don't want to advocate for either turning this rule on or off.
I've had some team member asking why we are using
return await
, especially after reading the current version of the documentation forno-return-await
. The reason we are usingreturn await
is because otherwise the functions are missing from the stack traces if an error is thrown asynchronously in the promise that is being returned.My intention with this change is to document that pitfall, and to clarify exactly what is being skipped when not using
return await
(that is, that the function is either still on the call stack, or not)I'm very open to suggestion on more improvements that we can do here! ❤️
Is there anything you'd like reviewers to focus on?
n/a