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-unused-vars] nois assigned a value but only used as a type error when it has a same name in export statement#11322

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
nayounsang wants to merge23 commits intotypescript-eslint:main
base:main
Choose a base branch
Loading
fromnayounsang:type-unused

Conversation

@nayounsang
Copy link
Contributor

@nayounsangnayounsang commentedJun 20, 2025•
edited
Loading

PR Checklist

Overview

Strict checks on exports with same type and variable name

  • If the name is the same, the variable isisTypeVariable && isValueVariable.
  • ClassName,TSEnumName,TSModuleName,ImportBinding andarguments also have same characteristics
  • Therefore, only the cases that correspond to the issue are properly verified.

Perform additional validating for abnormal cases

  • def.node.type !== AST_NODE_TYPES.TSTypeAliasDeclaration

Add test cases

  • tc mentioned in issue and similar but valid

@typescript-eslint
Copy link
Contributor

Thanks for the PR,@nayounsang!

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 commentedJun 20, 2025•
edited
Loading

✅ Deploy Preview fortypescript-eslint ready!

NameLink
🔨 Latest commitfccdd43
🔍 Latest deploy loghttps://app.netlify.com/projects/typescript-eslint/deploys/6925a2ead324580008709597
😎 Deploy Previewhttps://deploy-preview-11322--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: 91 (🔴 down 7 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.

@nayounsangnayounsang changed the titlefix(eslint-plugin): [no-unused-vars] nois assigned a value but only used as a type error when it has a same name type alias declaration exportefix(eslint-plugin): [no-unused-vars] nois assigned a value but only used as a type error when it has a same nameJun 20, 2025
@nx-cloud
Copy link

nx-cloudbot commentedJun 20, 2025•
edited
Loading

View yourCI Pipeline Execution ↗ for commita95d35e

CommandStatusDurationResult
nx test eslint-plugin --coverage=false✅ Succeeded5m 8sView ↗
nx run-many -t lint✅ Succeeded3m 14sView ↗
nx run-many -t typecheck✅ Succeeded2m 14sView ↗
nx run integration-tests:test✅ Succeeded6sView ↗
nx test eslint-plugin-internal --coverage=false✅ Succeeded3sView ↗
nx test typescript-estree --coverage=false✅ Succeeded2sView ↗
nx run types:build✅ Succeeded5sView ↗
nx run generate-configs✅ Succeeded8sView ↗
Additional runs (27)✅ Succeeded...View ↗

☁️Nx Cloud last updated this comment at2025-08-25 11:58:32 UTC

@codecov
Copy link

codecovbot commentedJun 20, 2025•
edited
Loading

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.88%. Comparing base (bd9e490) to head (a95d35e).
⚠️ Report is 162 commits behind head on main.

⚠️Current heada95d35e differs from pull request most recent headfccdd43

Pleaseupload reports for the commitfccdd43 to get more accurate results.

Additional details and impacted files
@@           Coverage Diff           @@##             main   #11322   +/-   ##=======================================  Coverage   90.87%   90.88%           =======================================  Files         505      505             Lines       51146    51157   +11       Branches     8424     8429    +5     =======================================+ Hits        46480    46494   +14+ Misses       4652     4649    -3  Partials       14       14
FlagCoverage Δ
unittest90.88% <100.00%> (+<0.01%)⬆️

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

Files with missing linesCoverage Δ
...s/eslint-plugin/src/util/collectUnusedVariables.ts96.86% <100.00%> (+0.67%)⬆️
🚀 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.

@nayounsang
Copy link
ContributorAuthor

Its a different issue:#8315, but we need to figure out if this is a workable solution.

@nayounsang
Copy link
ContributorAuthor

Its a different issue:#8315, but we need to figure out if this is a workable solution.

Ah, it is different. should change validate logic.
I think I need to work on another PR. If this PR is headed in the right direction.

@JoshuaKGoldberg
Copy link
Member

I think I need to work on another PR. If this PR is headed in the right direction.

@nayounsang apologies, I'm not following - are you suggesting we should or shouldn't review this PR?

@nayounsang
Copy link
ContributorAuthor

@JoshuaKGoldberg
Oh, please review this PR. I'm ready.

The comments are my own monologue. I tend to take notes of everything and I just saw another issue that seemed related to this PR. After looking into it, it seems that even if this PR is resolved, there will be additional work needed to resolve the other issues.

JoshuaKGoldberg reacted with thumbs up emoji

Copy link
Member

@JoshuaKGoldbergJoshuaKGoldberg 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.

🙌 Looks like a good start! I didn't review deeply because the.every line looks like it's either unnecessary or not fully tested. Which makes me suspect things might change up a bit. Could you please take a look?

@JoshuaKGoldbergJoshuaKGoldberg added the awaiting responseIssues waiting for a reply from the OP or another party labelJun 30, 2025
@github-actionsgithub-actionsbot removed the awaiting responseIssues waiting for a reply from the OP or another party labelJul 12, 2025
Copy link
Member

@bradzacherbradzacher left a comment

Choose a reason for hiding this comment

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

this is almost there -- but it misses this case:

constA=0;exportinterfaceA{}

Comment on lines 424 to 433
functionisMergedTypeDeclaration(
variable:Variable,
node:TSESTree.Node,
):boolean{
return(
node.type===AST_NODE_TYPES.TSTypeAliasDeclaration&&
variable.isTypeVariable&&
variable.isValueVariable
);
}
Copy link
Member

Choose a reason for hiding this comment

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

A better implementation to catch the interface case would leveragevariable.defs:

functionisMergedTypeDeclaration(variable:Variable,):boolean{return(variable.defs.length>1&&variable.isValueVariable&&variable.isTypeVariable&&variable.defs.some(d=>d.type===DefinitionType.Type));}

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

It can't cover this case:

// valid, but reportexportconstFoo=0;exporttypeFoo=typeofFoo;exportconstFoo=0;exportinterfaceFoo{}

What I meant was to check for theexport type Foo = ... statement. But in this case, it returns true if there are other type declarations besides theexport statement. This is becausenode exists within theexport statement when theisMergedTypeDeclaration is called.

So I've taken a different approach, can you please tell me if I'm going in the right direction?

@bradzacherbradzacher added the awaiting responseIssues waiting for a reply from the OP or another party labelAug 16, 2025
@nayounsangnayounsang changed the titlefix(eslint-plugin): [no-unused-vars] nois assigned a value but only used as a type error when it has a same namefix(eslint-plugin): [no-unused-vars] nois assigned a value but only used as a type error when it has a same name in export statementAug 17, 2025
@github-actionsgithub-actionsbot removed the awaiting responseIssues waiting for a reply from the OP or another party labelAug 17, 2025
JoshuaKGoldberg
JoshuaKGoldberg previously approved these changesSep 15, 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.

LGTM, thanks! I'll defer to@bradzacher as well on review. 👍

@JoshuaKGoldbergJoshuaKGoldberg added the 1 approval>=1 team member has approved this PR; we're now leaving it open for more reviews before we merge labelSep 15, 2025
Copy link
Member

@bradzacherbradzacher left a comment

Choose a reason for hiding this comment

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

There are the following 4 classes of cases here and we need to make sure we're reporting correctly on all of them.

////// case 1 -- both exported -- expected no reports///exportinterfaceFoo1{}exportconstFoo1=0;exporttypeBar1=0;exportconstBar1=0;exportconstFoo2=0;exportinterfaceFoo2{}exportconstBar2=0;exporttypeBar2=0;////// case 2 -- both exported via named export -- expected no reports///interfaceFoo7{}constFoo7=0;export{Foo7};typeBar7=0;constBar7=0;export{Bar7};constFoo8=0;interfaceFoo8{}export{Foo8};constBar8=0;typeBar8=0;export{Bar8};////// case 3 -- just value exported -- expected type is reported///interfaceFoo3{}exportconstFoo3=0;typeBar3=0;exportconstBar3=0;exportconstFoo4=0;interfaceFoo4{}exportconstBar4=0;typeBar4=0;////// case 4 -- just type exported -- expected value is reported///exportinterfaceFoo5{}constFoo5=0;exporttypeBar5=0;constBar5=0;constFoo6=0;exportinterfaceFoo6{}constBar6=0;exporttypeBar6=0;

The current implementation reports nothing on this code (which is technically half right heh).

Your current implementation:

  • does not report on case 1 -- ✔️
  • does not report on case 2 -- ✔️
  • does not report on case 3 -- ❌
  • reports on case 4 -- ✔️

PR branch playground

So we'll need to handle this and add test cases

JoshuaKGoldberg and nayounsang reacted with thumbs up emoji
@bradzacherbradzacher added awaiting responseIssues waiting for a reply from the OP or another party and removed 1 approval>=1 team member has approved this PR; we're now leaving it open for more reviews before we merge labelsOct 7, 2025
@nayounsang
Copy link
ContributorAuthor

nayounsang commentedOct 24, 2025•
edited
Loading

Hi.@bradzacher, There are some valid test cases I don't understand among the ones wrote before.
This is same withcase 3 -- just value exported -- expected type is reported on your comment.

    `interface Foo {  bar: string;}export const Foo = 'bar';    `,    `export const Foo = 'bar';interface Foo {  bar: string;}    `,

This is added from#6873
This is a PR that check all the declarations not just the first declaration.
At the time, the review seemed to have determined that the test case was not problematic. So I understood this to be an intended behavior.(In my personal opinion, a report is needed.) What do you think?
+cc@JoshuaKGoldberg

@bradzacher
Copy link
Member

@nayounsang the test cases may have been added in the past, but that doesn't mean they're right! They were right in so far as they allowed the rule to understand when a multi-declaration variable was exported in its second declaration, but the result is wrong.

interfaceFoo{//        ^^^ Type Foo is unusedbar:string;}exportconstFoo='bar';
exportconstFoo='bar';interfaceFoo{//        ^^^ Type Foo is unusedbar:string;}

This is what we should expect to report for these two cases -- we should be able to understand that the variable's second declaration is unused.

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

Reviewers

@bradzacherbradzacherbradzacher requested changes

@JoshuaKGoldbergJoshuaKGoldbergJoshuaKGoldberg left review comments

Requested changes must be addressed to merge this pull request.

Assignees

No one assigned

Labels

awaiting responseIssues waiting for a reply from the OP or another party

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Bug: [no-unused-vars] nois assigned a value but only used as a type error when it has a same name type alias declaration exported

3 participants

@nayounsang@JoshuaKGoldberg@bradzacher
[8]ページ先頭
©2009-2025 Movatter.jp