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

fix(eslint-plugin): [no-unnecessary-type-assertion] fix false negative for const variable declarations#8558

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

abrahamguo
Copy link
Contributor

@abrahamguoabrahamguo commentedFeb 27, 2024
edited by auvred
Loading

PR Checklist

Overview

Theno-unnecessary-type-assertions rule needs a bit more detail about when type assertions are truly useful or useless on literals.

@typescript-eslint
Copy link
Contributor

Thanks for the PR,@abrahamguo!

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 commentedFeb 27, 2024
edited
Loading

Deploy Preview fortypescript-eslint ready!

NameLink
🔨 Latest commit69f2cca
🔍 Latest deploy loghttps://app.netlify.com/sites/typescript-eslint/deploys/65f752740382d70008132bf6
😎 Deploy Previewhttps://deploy-preview-8558--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: 97 (🟢 up 4 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 commentedFeb 27, 2024
edited
Loading

☁️ Nx Cloud Report

CI is running/has finished running commands for commit69f2cca. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution


✅ Successfully ran 31 targets

Sent with 💌 fromNxCloud.

@codecovCodecov
Copy link

codecovbot commentedFeb 27, 2024
edited
Loading

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.09%. Comparing base(3856c67) to head(69f2cca).

Additional details and impacted files
@@            Coverage Diff             @@##             main    #8558      +/-   ##==========================================- Coverage   88.10%   88.09%   -0.02%==========================================  Files         402      402                Lines       14029    14015      -14       Branches     4117     4112       -5     ==========================================- Hits        12360    12346      -14  Misses       1370     1370                Partials      299      299
FlagCoverage Δ
unittest88.09% <100.00%> (-0.02%)⬇️

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

FilesCoverage Δ
...-plugin/src/rules/no-unnecessary-type-assertion.ts96.96% <100.00%> (-0.54%)⬇️

@auvredauvred added the awaiting responseIssues waiting for a reply from the OP or another party labelFeb 27, 2024
@auvredauvred removed the awaiting responseIssues waiting for a reply from the OP or another party labelFeb 27, 2024
Copy link
Member

@bradzacherbradzacher left a comment
edited
Loading

Choose a reason for hiding this comment

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

See the end of this comment#4485 (comment) for details of the changes we would accept to the rule.

Furthermore, the TSLint PR above also introduced some special handling for tuple types, which appears to be unnecessary, so it has been removed.

playground is this not the case that this assertion is required?

Or are you saying that the logic isn't required because it's never hit?

abrahamguo reacted with eyes emoji
@bradzacherbradzacher added the awaiting responseIssues waiting for a reply from the OP or another party labelFeb 27, 2024
@abrahamguo
Copy link
ContributorAuthor

abrahamguo commentedFeb 27, 2024
edited
Loading

is this not the case that this assertion is required?
Or are you saying that the logic isn't required because it's never hit?

@bradzacher this assertion is indeed required; however, no special handling is required for it (or, for any tuple types, I believe) in this lint rule becauseservices.getTypeAtLocation(node.expression) === castType returnsfalse.

@abrahamguo
Copy link
ContributorAuthor

Alrighty — I still need to clean up the tests a little bit, but I've reviewed (and added tests for):

and I am confident that my logic is correct for detecting useful vs useless literal type assertions:

  • First, as discussed above, any special logic for tuple type assertions is unnecessary. The base condition ofcastType === uncastType always returns false for any non-primitive type (in other words, this rule seems to do nothing at all for non-primitive types. Something to investigate for the future?)
  • The new logic is in thewouldSameTypeBeInferred variable. There are two cases to consider, depending on whethercastType.isLiteral() returnstrue orfalse.
  • Note thatcastType.isLiteral() only returnstrue if the type assertion is asingle literal. If it is a union of literals, for example, thencastType.isLiteral() will returnfalse.
  • ifcastType.isLiteral() returnstrue, then we know that the same type will be inferred, and therefore we are OK to report, if and only if we are within aconst variable declaration. Thisincludes reporting on anas const of a primitive within aconst variable declaration.
  • On the other hand, ifcastType.isLiteral() returns false, then we must be looking at a more complex type, and weshould report (assuming thattypeIsUnchanged is alsotrue)unless this is aconst assertion, in which case, do not report.

Things to investigate for the future:

  • Make this rule work for contextual typing (already noted as a TODO)
  • Make this rule work for non-primitives (did it ever in the past? unsure)

@github-actionsgithub-actionsbot removed the awaiting responseIssues waiting for a reply from the OP or another party labelFeb 29, 2024
Copy link
Member

@auvredauvred left a comment

Choose a reason for hiding this comment

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

Overall looks good to me! Thanks for working on this! 🚀

Just requesting splitting the test cases

Comment on lines +109 to +115
function isConstVariableDeclaration(node: TSESTree.Node): boolean {
return (
node.type === AST_NODE_TYPES.VariableDeclaration &&
node.kind === 'const'
);
}

Copy link
Member

Choose a reason for hiding this comment

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

[non-actionable] Hmmm, looks like these cases are not reported (playground)

leta:unknownconstb=(a=1as1)constc=(console.log(1),1as1)

However, I'm not sure we can easily detect all such cases. This function might become too complex...

abrahamguo reacted with eyes emoji

Choose a reason for hiding this comment

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

Yeah I think we can leave these for now. If someone files an issue showing them being buggy in isolation, then that'd indicate there's enough user appetite to start thinking about whether the complexity is worth it.

@auvredauvred changed the titlefix: fix false negative for const variable declarations inno-unnecessary-type-assertionfix(eslint-plugin): [no-unnecessary-type-assertion] fix false negative for const variable declarationsMar 4, 2024
@auvredauvred added the awaiting responseIssues waiting for a reply from the OP or another party labelMar 4, 2024
@abrahamguoabrahamguo requested a review fromauvredMarch 4, 2024 13:03
@github-actionsgithub-actionsbot removed the awaiting responseIssues waiting for a reply from the OP or another party labelMar 4, 2024
Copy link
Member

@auvredauvred left a comment

Choose a reason for hiding this comment

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

Getting closer! 🙌

I think the main blocker in my mind is updating correct example in the docs

@auvredauvred added the awaiting responseIssues waiting for a reply from the OP or another party labelMar 6, 2024
abrahamguoand others added3 commitsMarch 7, 2024 06:58
Co-authored-by: auvred <61150013+auvred@users.noreply.github.com>
@abrahamguoabrahamguo requested a review fromauvredMarch 7, 2024 13:06
@github-actionsgithub-actionsbot removed the awaiting responseIssues waiting for a reply from the OP or another party labelMar 7, 2024
auvred
auvred previously approved these changesMar 7, 2024
Copy link
Member

@auvredauvred left a comment

Choose a reason for hiding this comment

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

LGTM 🔥

Thanks for working on this!

guy applauds

@auvredauvred added the 1 approval>=1 team member has approved this PR; we're now leaving it open for more reviews before we merge labelMar 13, 2024
JoshuaKGoldberg
JoshuaKGoldberg previously approved these changesMar 17, 2024
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.

🙌 swell, thanks!

abrahamguo reacted with hooray emoji
@JoshuaKGoldbergJoshuaKGoldberg merged commitd2995df intotypescript-eslint:mainMar 18, 2024
@github-actionsgithub-actionsbot locked asresolvedand limited conversation to collaboratorsMar 26, 2024
@abrahamguoabrahamguo deleted the no-unnecessary-type-assertion branchApril 2, 2024 01:12
Sign up for freeto subscribe to this conversation on GitHub. Already have an account?Sign in.
Reviewers

@JoshuaKGoldbergJoshuaKGoldbergJoshuaKGoldberg left review comments

@auvredauvredauvred left review comments

@bradzacherbradzacherAwaiting requested review from bradzacher

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.

Docs: [no-unnecessary-type-assertion] incorrect examples don't report errors [no-unnecessary-type-assertion] only checks non-null-assertion
4 participants
@abrahamguo@JoshuaKGoldberg@bradzacher@auvred

[8]ページ先頭

©2009-2025 Movatter.jp