Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

feat(eslint-plugin): [no-unnecessary-condition] makeallowConstantLoopConditions 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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation

ronami
Copy link
Member

@ronamironami commentedJan 11, 2025•
edited
Loading

PR Checklist

Overview

This PR attempts to tackle#7047 and changesallowConstantLoopConditions 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 (minusneverExceptWhileTrue).

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).

@typescript-eslint
Copy link
Contributor

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 onhttps://opencollective.com/typescript-eslint.

@netlifyNetlify
Copy link

netlifybot commentedJan 11, 2025•
edited
Loading

✅ Deploy Preview fortypescript-eslint ready!

NameLink
🔨 Latest commit10c8e97
🔍 Latest deploy loghttps://app.netlify.com/sites/typescript-eslint/deploys/67a28d0934c3a200083621b7
😎 Deploy Previewhttps://deploy-preview-10639--typescript-eslint.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
Lighthouse
Lighthouse		1 paths audited
Performance: 98 (🔴 down 1 from production)
Accessibility: 100 (no change from production)
Best Practices: 92 (no change from production)
SEO: 98 (no change from production)
PWA: 80 (no change from production)
View the detailed breakdown and full score reports

To edit notification comments on pull requests, go to yourNetlify site configuration.

@nx-cloudNx Cloud
Copy link

nx-cloudbot commentedJan 11, 2025•
edited
Loading

View yourCI Pipeline Execution ↗ for commit10c8e97.

CommandStatusDurationResult
nx test eslint-plugin --coverage=false✅ Succeeded7m 24sView ↗
nx test eslint-plugin✅ Succeeded5m 58sView ↗
nx test utils --coverage=false✅ Succeeded<1sView ↗
nx test typescript-eslint --coverage=false✅ Succeeded8sView ↗
nx test visitor-keys --coverage=false✅ Succeeded<1sView ↗
nx test type-utils --coverage=false✅ Succeeded<1sView ↗
nx run types:build✅ Succeeded<1sView ↗
nx test visitor-keys✅ Succeeded<1sView ↗
Additional runs (24)✅ Succeeded...View ↗

☁️Nx Cloud last updated this comment at2025-02-04 22:11:19 UTC

@codecovCodecov
Copy link

codecovbot commentedJan 11, 2025•
edited
Loading

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.28%. Comparing base(81dc579) to head(10c8e97).
Report is 78 commits behind head on main.

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
FlagCoverage Δ
unittest87.28% <100.00%> (+0.34%)⬆️

Flags with carried forward coverage won't be shown.Click here to find out more.

Files with missing linesCoverage Δ
...slint-plugin/src/rules/no-unnecessary-condition.ts99.20% <100.00%> (-0.04%)⬇️

... and115 files with indirect coverage changes

@ronamironami marked this pull request as ready for reviewJanuary 11, 2025 20:59
Copy link
Member

@JoshuaKGoldbergJoshuaKGoldberg left a 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, sinceonlyTrue is a lot cleaner IMO.

ronami reacted with heart emoji
@JoshuaKGoldbergJoshuaKGoldberg added the awaiting responseIssues waiting for a reply from the OP or another party labelJan 19, 2025
@github-actionsgithub-actionsbot removed the awaiting responseIssues waiting for a reply from the OP or another party labelJan 21, 2025
@kirkwaiblingerkirkwaiblinger added the awaiting responseIssues waiting for a reply from the OP or another party labelJan 24, 2025
@github-actionsgithub-actionsbot removed the awaiting responseIssues waiting for a reply from the OP or another party labelJan 27, 2025
@@ -84,12 +84,70 @@ function bar(arg?: string | null) {

{/* insert option description */}

Example of correct code for `{ allowConstantLoopConditions: true }`:
#### `'never'` or `false`

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 thetrue/false a bit to nudge users towards the string options now... As a random example from the top of my head, thevscode 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.

ronami reacted with thumbs up emojironami reacted with eyes emoji
Copy link
MemberAuthor

@ronamironamiFeb 4, 2025•
edited
Loading

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 onetypescript-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?

I guess that another option is to stick withtrue,false, andonly-allowed-literals (I've seen thisdone here andalso 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?

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 onetypescript-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 thetrue/false option types to be deprecated in this PR but maybe others will have opinions.

I guess that another option is to stick withtrue,false, andonly-allowed-literals (I've seen thisdone here andalso 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!

ronami reacted with thumbs up emojironami reacted with rocket emoji
@kirkwaiblingerkirkwaiblinger added the awaiting responseIssues waiting for a reply from the OP or another party labelFeb 2, 2025
@github-actionsgithub-actionsbot removed the awaiting responseIssues waiting for a reply from the OP or another party labelFeb 4, 2025
Copy link
Member

@kirkwaiblingerkirkwaiblinger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

happy

ronami reacted with heart emoji
@kirkwaiblingerkirkwaiblinger added the 1 approval>=1 team member has approved this PR; we're now leaving it open for more reviews before we merge labelFeb 10, 2025
Copy link
Member

@JoshuaKGoldbergJoshuaKGoldberg left a 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!

ronami reacted with heart emoji
@JoshuaKGoldbergJoshuaKGoldberg merged commitac8dde0 intotypescript-eslint:mainFeb 10, 2025
62 of 63 checks passed
@ronamironami deleted the no-unnecessary-condition-allowConstantLoopConditions branchFebruary 10, 2025 16:51
renovatebot added a commit to andrei-picus-tink/auto-renovate that referenced this pull requestFeb 11, 2025
| 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 AmielYou 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.
renovatebot added a commit to andrei-picus-tink/auto-renovate that referenced this pull requestFeb 11, 2025
| 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 AmielYou 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.
@github-actionsgithub-actionsbot locked asresolvedand limited conversation to collaboratorsFeb 18, 2025
Sign up for freeto subscribe to this conversation on GitHub. Already have an account?Sign in.
Reviewers

@kirkwaiblingerkirkwaiblingerkirkwaiblinger approved these changes

@JoshuaKGoldbergJoshuaKGoldbergJoshuaKGoldberg approved these changes

Assignees
No one assigned
Labels
1 approval>=1 team member has approved this PR; we're now leaving it open for more reviews before we merge
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Enhancement: [no-unnecessary-condition] Make allowConstantLoopConditions more granular
3 participants
@ronami@JoshuaKGoldberg@kirkwaiblinger
[8]ページ先頭
©2009-2025 Movatter.jp