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] flag unnecessary type predicates based on assignability#11735

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

Open
azat-io wants to merge3 commits intotypescript-eslint:main
base:main
Choose a base branch
Loading
fromazat-io:feat/no-unnecessary-condition-array

Conversation

@azat-io
Copy link
Contributor

PR Checklist

Overview

Adds detection of redundant Array.isArray() calls when checkTypePredicates is enabled.

Reports error when the argument is already typed as an array (including readonly arrays).

@typescript-eslint
Copy link
Contributor

Thanks for the PR,@azat-io!

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.

@netlify
Copy link

netlifybot commentedNov 3, 2025
edited
Loading

Deploy Preview fortypescript-eslint ready!

NameLink
🔨 Latest commitb6dcb7d
🔍 Latest deploy loghttps://app.netlify.com/projects/typescript-eslint/deploys/69090e705cf8d30008a4e378
😎 Deploy Previewhttps://deploy-preview-11735--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: 93 (🔴 down 3 from production)
Accessibility: 97 (no change from production)
Best Practices: 100 (no change from production)
SEO: 92 (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 project configuration.

@nx-cloud
Copy link

nx-cloudbot commentedNov 3, 2025
edited
Loading

🤖 Nx Cloud AI Fix Eligible

An automatically generated fix could have helped fix failing tasks for this run, but Self-healing CI is disabled for this workspace. Visit workspace settings to enable it and get automatic fixes in future runs.

To disable these notifications, a workspace admin can disable themin workspace settings.


View yourCI Pipeline Execution ↗ for commitb6dcb7d

CommandStatusDurationResult
nx run-many -t lint❌ Failed3m 14sView ↗
nx test eslint-plugin --coverage=false✅ Succeeded5m 11sView ↗
nx run-many -t typecheck✅ Succeeded2m 5sView ↗
nx run integration-tests:test✅ Succeeded3sView ↗
nx test eslint-plugin-internal --coverage=false✅ Succeeded3sView ↗
nx test typescript-estree --coverage=false✅ Succeeded1sView ↗
nx run types:build✅ Succeeded5sView ↗
nx run generate-configs✅ Succeeded7sView ↗
Additional runs (29)✅ Succeeded...View ↗

☁️Nx Cloud last updated this comment at2025-11-03 20:31:34 UTC


{
code:`
const items: number[] | null = [1, 2, 3];

Choose a reason for hiding this comment

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

You'll want to do it like this, I think, here and elsewhere:

Suggested change
constitems:number[]|null=[1,2,3];
declareconstitems:number[]|null;

TS ignores the| null because it can see that it's not null (playgroun)

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Done ✅

Choose a reason for hiding this comment

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

If I replace this entire diff with

-          if (typeOfArgument === typeGuardAssertedArgument.type) {+          if (+            checker.isTypeAssignableTo(+              typeOfArgument,+              typeGuardAssertedArgument.type,+            )+          ) {

(which is what was intended in#11716 (comment)), the only test case that doesn't pass (apart from spurious reasons) is

functionprocessArray(arr:readonlystring[]){if(Array.isArray(arr)){returnarr.length;}}

So, I'm still thinking that changing to the assignability API makes sense, at least as a first step. In other words, let's take on the assignability API change before worrying about the edge case ofreadonly arrays withArray.isArray() (which, FWIW, I think is basically a corollary ofmicrosoft/TypeScript#17002). What do you think?

Also cc@ronami

ronami reacted with thumbs up emoji
Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Done! Changed to usechecker.isTypeAssignableTo() for Array.isArray

Choose a reason for hiding this comment

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

@azat-io almost! I really mean the entire diff, though, not just the Array.isArray case. The thought is to change all unnecessary type predicate detection to be based on assignability.

Note that this change would require accompanying report message changes and additional testing

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Done! Changed to useisTypeAssignableTo() for all type predicates. RemovedisArrayIsArrayCall() function and updated the tests accordingly.

@codecov
Copy link

codecovbot commentedNov 3, 2025
edited
Loading

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.67%. Comparing base (bb451a1) to head (b6dcb7d).
⚠️ Report is 6 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@##             main   #11735   +/-   ##=======================================  Coverage   90.66%   90.67%           =======================================  Files         518      518             Lines       52415    52440   +25       Branches     8678     8686    +8     =======================================+ Hits        47521    47548   +27+ Misses       4880     4878    -2  Partials       14       14
FlagCoverage Δ
unittest90.67% <100.00%> (+<0.01%)⬆️

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.57% <100.00%> (+<0.01%)⬆️

... and3 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@kirkwaiblingerkirkwaiblinger changed the titlefeat(eslint-plugin): [no-unnecessary-condition] detect unnecessaryArray.isArray callsfeat(eslint-plugin): [no-unnecessary-condition] flag unnecessary type predicates based on assignabilityNov 3, 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.

I don't have time to do a fully detailed review right now, but jotting down the notes that I'll want to come back to. Feel free to look into these in the meantime:

  1. We'll probably need to update the text of the typeGuardAlreadyIsType message.
  2. ThegetConstrainedTypeAtLocation may actually be wrong/unnecessary now. Needs tests with generics to prove one way or another.
  3. Like with no-unsafe-type-assertion, we should double-check and add testing around object literals and excess property checking.
  4. Needs further tests around subtype cases.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@kirkwaiblingerkirkwaiblingerkirkwaiblinger requested changes

Requested changes must be addressed to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Enhancement: [no-unnecessary-condition] detect unnecessary calls to Array.isArray

2 participants

@azat-io@kirkwaiblinger

[8]ページ先頭

©2009-2025 Movatter.jp