Skip to content

Deprecate return-await option "never" #9433

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

Closed
kirkwaiblinger opened this issue Jun 25, 2024 · 4 comments · Fixed by #9364
Closed

Deprecate return-await option "never" #9433

kirkwaiblinger opened this issue Jun 25, 2024 · 4 comments · Fixed by #9364
Assignees
Labels
documentation Documentation ("docs") that needs adding/updating locked due to age Please open a new issue if you'd like to say more. See https://typescript-eslint.io/contributing. package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin team assigned A member of the typescript-eslint team should work on this.

Comments

@kirkwaiblinger
Copy link
Member

kirkwaiblinger commented Jun 25, 2024

Overview

Doc: https://typescript-eslint.io/rules/return-await#never

The "never" option really just enforces wrong and confusing behavior in error-handling scenarios. In #9364 (comment) / #9364 (comment) we're trying to update the docs in return-await and I'm finding it hard to say when you would want to use the option. @JoshuaKGoldberg and I are thinking this may be a reasonable time to just deprecate it rather than trying too hard to find something nice to say.

Note that

It looks like very few people are using this option: https://sourcegraph.com/search?q=context:global+file:.*eslint%7Cjs%7Cjson%7Cyaml%7Cyml%7Cyaml.*+/%40typescript-eslint%5C/return-await.*never/+-file:.*node_modules.*+-file:dist%5C/.*+count:200000&patternType=standard&sm=0

I propose we document it as deprecated (in #9364), to be removed in a future major version.

@kirkwaiblinger kirkwaiblinger added package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin triage Waiting for team members to take a look labels Jun 25, 2024
@kirkwaiblinger
Copy link
Member Author

kirkwaiblinger commented Jun 25, 2024

One thing to add - if anyone wants to prohibit all return await, and prefers const x = await foo; return x; (as suggested in #994 (comment)), I would recommend:

  • use no restricted syntax selector: ReturnStatement > AwaitExpression;
  • AND enable return-await with 'always'.

That way, neither return promise or return await promise will ever be legal, and you'll be forced to add an intermediate variable.

That is a better solution IMO than the 'never' option would have been, since the 'never' option still allows return promise.

@rubiesonthesky
Copy link
Contributor

I think if never is removed, it would be good to document what is said above and how to achieve same result.

That table that is worked on linked issue helps to understand these settings. But just a feedback, I think it’s not been very clear what the options do and when you want to use which option. I kinda thought that “never” would mean that you always need to return promise, I.e. you can’t return variable that was awaited earlier.

As a side note, I sometimes wish there was page where you could see list of useful syntax to disallow with some examples. There are a lot of cases where ban syntax would be enough instead of creating new rule. It’s just an option that it’s easy to forget.

@Josh-Cena
Copy link
Member

As a side note, I sometimes wish there was page where you could see list of useful syntax to disallow with some examples.

#5863

@kirkwaiblinger
Copy link
Member Author

But just a feedback, I think it’s not been very clear what the options do and when you want to use which option.

Fully agree! This and some of the other promise rules are an area of active focus for improving the docs, and clarity in general. 🙂

@JoshuaKGoldberg JoshuaKGoldberg added documentation Documentation ("docs") that needs adding/updating accepting prs Go ahead, send a pull request that resolves this issue and removed triage Waiting for team members to take a look labels Jun 28, 2024
@kirkwaiblinger kirkwaiblinger self-assigned this Jul 1, 2024
@kirkwaiblinger kirkwaiblinger added team assigned A member of the typescript-eslint team should work on this. and removed accepting prs Go ahead, send a pull request that resolves this issue labels Jul 1, 2024
@github-actions github-actions bot added the locked due to age Please open a new issue if you'd like to say more. See https://typescript-eslint.io/contributing. label Jul 27, 2024
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 27, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
documentation Documentation ("docs") that needs adding/updating locked due to age Please open a new issue if you'd like to say more. See https://typescript-eslint.io/contributing. package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin team assigned A member of the typescript-eslint team should work on this.
Projects
None yet
4 participants