-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
feat(eslint-plugin): [no-unnecessary-condition] make allowConstantLoopConditions
more granular
#10639
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
feat(eslint-plugin): [no-unnecessary-condition] make allowConstantLoopConditions
more granular
#10639
Conversation
Thanks for the PR, @ronami! typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community. The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately. Thanks again! 🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. |
✅ Deploy Preview for typescript-eslint ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
View your CI Pipeline Execution ↗ for commit 10c8e97.
☁️ Nx Cloud last updated this comment at |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #10639 +/- ##
==========================================
+ Coverage 86.94% 87.28% +0.34%
==========================================
Files 446 450 +4
Lines 15508 15750 +242
Branches 4518 4613 +95
==========================================
+ Hits 13484 13748 +264
+ Misses 1669 1645 -24
- Partials 355 357 +2
Flags with carried forward coverage won't be shown. Click here to find out more.
|
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.
🚀 Whoohoo! Thanks for taking on this old issue, it's been bugging me for ages!
I agree with the implementation and direction. Keeping the legacy options around to make this non-breaking seems reasonable + necessary to me.
Just requesting changes on the name, since onlyTrue
is a lot cleaner IMO.
@@ -84,12 +84,70 @@ function bar(arg?: string | null) { | |||
|
|||
{/* insert option description */} | |||
|
|||
Example of correct code for `{ allowConstantLoopConditions: true }`: | |||
#### `'never'` or `false` |
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.
I'm wondering if we can de-emphasize the true
/false
a bit to nudge users towards the string options now... As a random example from the top of my head, the vscode docs about code actions on save just give the string name in the header and mention the legacy boolean alias as an afterthought. Probably there are many more examples to draw from in the ecosystem.
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.
Interesting! I like this, especially since this will probably (I assume) be removed or deprecated in the next major.
The closet I could find one typescript-eslint
's repo is possibly TypeOrValueSpecifier
's universal string specifiers (which isn't too similar). If these options would be removed or deprecated, should this have a note on the docs to warn about this potentially?
I guess that another option is to stick with true
, false
, and only-allowed-literals
(I've seen this done here and also here for example).
I updated the PR to remove this from the header and down to the description (similar to the linked vscode example).
Another option I'm thinking of is the order of these three options: currently 'never'
shows up first, followed by 'always'
, with 'only-allowed-literals'
being last (even though it's probably [I'm assuming] the recommended way to go).
Should it potentially be the first option to promote users using it, at least until it's changed to the default?
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.
Interesting! I like this, especially since this will probably (I assume) be removed or deprecated in the next major.
The closet I could find one
typescript-eslint
's repo is possiblyTypeOrValueSpecifier
's universal string specifiers (which isn't too similar). If these options would be removed or deprecated, should this have a note on the docs to warn about this potentially?
Eh, I don't think there's any value in adding a pre-deprecated state 🙃 I personally would be happy for the true
/false
option types to be deprecated in this PR but maybe others will have opinions.
I guess that another option is to stick with
true
,false
, andonly-allowed-literals
(I've seen this done here and also here for example).
My reaction to this is 🤮, haha
I updated the PR to remove this from the header and down to the description (similar to the linked vscode example).
Another option I'm thinking of is the order of these three options: currently
'never'
shows up first, followed by'always'
, with'only-allowed-literals'
being last (even though it's probably [I'm assuming] the recommended way to go).Should it potentially be the first option to promote users using it, at least until it's changed to the default?
Hmm. I don't have a strong opinion. Probably the default first is best and we can change the order if we change the default in the future? Whatever you think is best!
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.
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.
🚀 Very nice how this ended up!
ac8dde0
into
typescript-eslint:main
| datasource | package | from | to | | ---------- | -------------------------------- | ------ | ------ | | npm | @typescript-eslint/eslint-plugin | 8.23.0 | 8.24.0 | | npm | @typescript-eslint/parser | 8.23.0 | 8.24.0 | ## [v8.24.0](https://github.com/typescript-eslint/typescript-eslint/blob/HEAD/packages/eslint-plugin/CHANGELOG.md#8240-2025-02-10) ##### 🚀 Features - **eslint-plugin:** \[no-unnecessary-condition] make `allowConstantLoopConditions` more granular ([#10639](typescript-eslint/typescript-eslint#10639)) ##### 🩹 Fixes - **eslint-plugin:** \[no-misused-spread] correct and elaborate string spread report message ([#10751](typescript-eslint/typescript-eslint#10751)) - **eslint-plugin:** \[restrict-plus-operands] report adding bigints to strings when `allowNumberAndString` is `false` ([#10737](typescript-eslint/typescript-eslint#10737)) ##### ❤️ Thank You - Josh Goldberg ✨ - noah - Ronen Amiel You can read about our [versioning strategy](https://main--typescript-eslint.netlify.app/users/versioning) and [releases](https://main--typescript-eslint.netlify.app/users/releases) on our website.
| datasource | package | from | to | | ---------- | -------------------------------- | ------ | ------ | | npm | @typescript-eslint/eslint-plugin | 8.23.0 | 8.24.0 | | npm | @typescript-eslint/parser | 8.23.0 | 8.24.0 | ## [v8.24.0](https://github.com/typescript-eslint/typescript-eslint/blob/HEAD/packages/eslint-plugin/CHANGELOG.md#8240-2025-02-10) ##### 🚀 Features - **eslint-plugin:** \[no-unnecessary-condition] make `allowConstantLoopConditions` more granular ([#10639](typescript-eslint/typescript-eslint#10639)) ##### 🩹 Fixes - **eslint-plugin:** \[no-misused-spread] correct and elaborate string spread report message ([#10751](typescript-eslint/typescript-eslint#10751)) - **eslint-plugin:** \[restrict-plus-operands] report adding bigints to strings when `allowNumberAndString` is `false` ([#10737](typescript-eslint/typescript-eslint#10737)) ##### ❤️ Thank You - Josh Goldberg ✨ - noah - Ronen Amiel You can read about our [versioning strategy](https://main--typescript-eslint.netlify.app/users/versioning) and [releases](https://main--typescript-eslint.netlify.app/users/releases) on our website.
PR Checklist
Overview
This PR attempts to tackle #7047 and changes
allowConstantLoopConditions
from aboolean
to the followingenum
:'never'
: same as the currentfalse
'neverExceptWhileTrue'
: disallows constant conditions in all loops exceptwhile
loops with the literaltrue
.'always'
: same as the currenttrue
This is a non-breaking change as the existing options map to the new option (minus
neverExceptWhileTrue
).Some thoughts:
I've used a similar option name for
'neverExceptWhileTrue'
asno-constant-condition
'scheckLoops
. The option name is somewhat limiting because it's so specific, it may be better to have an option name that's a bit less specific to allow future changes(?).The original issue suggests that the default may be changed on a future major. However, since
'neverExceptWhileTrue'
is similar to the current default ('never'
) but allows for an additional use-case, I think it can be considered to become the new default, especially since the pattern it allows is relatively common (or so I think).