Skip to content

feat(eslint-plugin): add a default-off option to autofix remove unused imports #11243

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

Open
wants to merge 20 commits into
base: main
Choose a base branch
from

Conversation

nayounsang
Copy link

@nayounsang nayounsang commented May 23, 2025

PR Checklist

Overview

Auto fix unused import statements

  • Test cases that correspond to the issue can be fixed

examples

import Unused1 from 'foo';
import Unused2, { Used } from 'bar';
export { Used };

import { Used } from 'bar';
export { Used };

// -------------------
import { Unused1 } from 'foo';
import Used1, { Unused2 } from 'bar';
import { Used2, Unused3 } from 'baz';
import Used3, { Unused4, Used4 } from 'foobar';
export { Used1, Used2, Used3, Used4 };

import Used1 from 'bar';
import { Used2 } from 'baz';
import Used3, { Used4 } from 'foobar';
export { Used1, Used2, Used3, Used4 };

// -----------------
import { /* cmt */ Unused1, Used1 } from 'foo';
export { Used1 };

import { /* cmt */ Used1 } from 'foo';
export { Used1 };

// ------------------
import type { UnusedType } from 'foo';
import { Used1, Unused1 } from 'foo';
export { Used1 };

import { Used1 } from 'foo';
export { Used1 };

// -----------------
import { Unused1 as u1, Used1 as u2 } from 'foo';
export { u2 };

import { Used1 as u2 } from 'foo';
export { u2 };

Currently logically impossible (commented test cases)

  • write an import statement in multiple lines
  • If there are multiple unused specifiers in an import statement

examples

import { Unused1, Unused2, Used1 } from 'foo';
import { Unused3, Unused4 } from 'bar';
export { Used1 };

// expect
import { Used1 } from 'foo';
export { Used1 };

// received
import { Unused2, Used1 } from 'foo';
import { Unused4 } from 'bar';
export { Used1 };

// ----------------------
import {
  Unused1,
  Unused2,
  Unused3,
  Unused4,
  Used1,
  /* cmt */
  Unused5,
  Unused6,
  Used2,
} from 'foo';
export { Used1, Used2 };

// expect (currently skip this case)
import {
  Used1,
  /* cmt */
  Used2,
} from 'foo';
export { Used1, Used2 };

Guessing about the failed(commented) test case: remove multiple unused vars in one-line

  • Conflict between fixer
  • To solve this, I need to remove all specifiers on the same line. (return fixer.remove as an array?)
  • Therefore, we need to check whether each specifer is unused before calling the fixer function.

@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 on https://opencollective.com/typescript-eslint.

Copy link

netlify bot commented May 23, 2025

Deploy Preview for typescript-eslint ready!

Name Link
🔨 Latest commit 6de9050
🔍 Latest deploy log https://app.netlify.com/projects/typescript-eslint/deploys/6845a18d15f3020008de847b
😎 Deploy Preview https://deploy-preview-11243--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: 99 (no change from production)
Accessibility: 100 (no change from production)
Best Practices: 100 (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 your Netlify project configuration.

@nayounsang nayounsang marked this pull request as draft May 23, 2025 15:53
Copy link

nx-cloud bot commented May 23, 2025

View your CI Pipeline Execution ↗ for commit 6de9050.

Command Status Duration Result
nx test eslint-plugin --coverage=false ✅ Succeeded 5m 4s View ↗
nx run-many -t typecheck ✅ Succeeded 2m 10s View ↗
nx run-many -t lint ✅ Succeeded 10s View ↗
nx test eslint-plugin-internal --coverage=false ✅ Succeeded <1s View ↗
nx run types:build ✅ Succeeded <1s View ↗
nx run integration-tests:test ✅ Succeeded <1s View ↗
nx test typescript-estree --coverage=false ✅ Succeeded <1s View ↗
nx run generate-configs ✅ Succeeded 4s View ↗
Additional runs (27) ✅ Succeeded ... View ↗

☁️ Nx Cloud last updated this comment at 2025-06-08 14:55:31 UTC

@nayounsang
Copy link
Author

Wow, when adding a new feature, a follow-up development is needed. I'll work on it tomorrow.

Copy link

codecov bot commented May 24, 2025

Codecov Report

Attention: Patch coverage is 94.59459% with 4 lines in your changes missing coverage. Please review.

Project coverage is 90.92%. Comparing base (1e0ba62) to head (6de9050).

Files with missing lines Patch % Lines
packages/eslint-plugin/src/rules/no-unused-vars.ts 94.59% 4 Missing ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##             main   #11243   +/-   ##
=======================================
  Coverage   90.91%   90.92%           
=======================================
  Files         501      501           
  Lines       50869    50943   +74     
  Branches     8382     8403   +21     
=======================================
+ Hits        46248    46318   +70     
- Misses       4606     4610    +4     
  Partials       15       15           
Flag Coverage Δ
unittest 90.92% <94.59%> (+<0.01%) ⬆️

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

Files with missing lines Coverage Δ
packages/eslint-plugin/src/rules/no-unused-vars.ts 99.41% <94.59%> (-0.59%) ⬇️
🚀 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 nayounsang marked this pull request as ready for review June 5, 2025 06:13
Copy link
Member

@kirkwaiblinger kirkwaiblinger left a comment

Choose a reason for hiding this comment

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

A great start!

I'm leaving a bit of a drive-by review since I see that there are several major TODOs in the code that need to get resolved. Feel free to reach out if you're looking for help with those! In the meantime, I'm going to leave a Changes Requested review so that this isn't in our ready-to-review queue.

Thanks!


const source = context.sourceCode;
const node = def.node;
const decl = node.parent as TSESTree.ImportDeclaration;
Copy link
Member

Choose a reason for hiding this comment

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

I think that this will be unsound for import = require-style imports, for example

import x = require('foo')

Let's be sure to include some test coverage with that style of import.

Copy link
Author

@nayounsang nayounsang Jun 6, 2025

Choose a reason for hiding this comment

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

Oh, nice catch. This is TSImportEqualsDeclaration type.
I test with this code:

    {
      code: `
import x = require('foo');
import y = require('bar');
export { y };
      `,
      errors: [{ messageId: 'unusedVar' }],
      options: [{ enableAutofixRemoval: { imports: true } }],
      output: `
import y = require('bar');
export { y };
      `,
    }

In the existing logic, an error occurs and a more accurate logic is used rather than type casting.
related commit: 11ac4fa

@@ -687,6 +708,80 @@ export default createRule<Options, MessageIds>({
data: unusedVar.references.some(ref => ref.isWrite())
? getAssignedMessageData(unusedVar)
: getDefinedMessageData(unusedVar),
fix: options.enableAutofixRemoval?.imports
Copy link
Member

Choose a reason for hiding this comment

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

This seems useful as a suggestion, even if the autofix option is disabled. Consider using getFixOrSuggest to conditionally provide this fix as a suggestion?

export function getFixOrSuggest<MessageId extends string>({
fixOrSuggest,
suggestion,
}: {
fixOrSuggest: 'fix' | 'none' | 'suggest';
suggestion: TSESLint.SuggestionReportDescriptor<MessageId>;
}):
| { fix: TSESLint.ReportFixFunction }
| { suggest: TSESLint.SuggestionReportDescriptor<MessageId>[] }
| undefined {
switch (fixOrSuggest) {
case 'fix':
return { fix: suggestion.fix };
case 'none':
return undefined;
case 'suggest':
return { suggest: [suggestion] };
}
}

Copy link
Author

Choose a reason for hiding this comment

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

Good idea. However, it would be better to provide suggestions to existing test cases and then resolve this comment before processing.

if (decl.specifiers.length === 1) {
return fixer.removeRange([
decl.range[0],
decl.range[1] + 1, // +1 to include "\n"
Copy link
Member

Choose a reason for hiding this comment

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

to include "\n"

Why do we want to do this exactly? This causes a bug with this technically valid code (please include as a test case - hint, you'll need to use noFormat):

import x from 'foo';import y from 'bar'

My instinct is to say we're better off just leaving a blank line and letting the user decide how to format it afterwards (whether by hand or with prettier or similar).

Copy link
Author

@nayounsang nayounsang Jun 6, 2025

Choose a reason for hiding this comment

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

we're better off just leaving a blank line and letting the user decide how to format it afterwards (whether by hand or with prettier or similar).

Wow, that's right. That should have been it. Plus, it lowers the difficulty of solving the problem and the code becomes simpler.
related commit: 9f76441 & 633d2c8

Copy link
Author

Choose a reason for hiding this comment

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

Add new message: unusedVarSuggestion. However, I'm concerned about the proposed message: Remove unused variable.. Any thoughts?

related commit: 2c8b740 & 9a15d49

@kirkwaiblinger kirkwaiblinger added the awaiting response Issues waiting for a reply from the OP or another party label Jun 6, 2025
`,
},
// TODO: Logic to remove multiple unused vars in one-line
// {
Copy link
Author

Choose a reason for hiding this comment

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

The reason for this was that the fixer conflict was right.

import Unused1, { Unused2, Unused3 } from "foo";
import { Unused4, Unused5, Unused6 } from "bar";

The cases that occur are as follows:

import Unused1, { Unused2 } from "foo";
import { Unused4, Unused5, Unused6 } from "bar";
  1. If the number of ImportDefaultSpecifiers + the number of ImportSpecifiers in a single line of ImportDeclaration is 2 or more and all of them are unused.
    playground
import Used1, { Unused4, Unused5, Unused6 } from "bar";
export { Used1 };
  1. If there are more than 2 ImportSpecifiers in a single line of ImportDeclaration and they are all unused
    playground

WHY?
This is because, after deleting one ImportSpecifier or ImportDefaultSpecifer respectively, it tries to delete a line if only one remains and it is not used.

Copy link
Author

@nayounsang nayounsang Jun 7, 2025

Choose a reason for hiding this comment

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

Current

  1. Fixer see Unused1, and remove range(Unused1,)
  2. Fixer see Unused2, and remove range(Unused2,)
  3. Fixer see Unused3, since there is only one Specifier left, fixer remove range(Declaration), CONFLICT

Plan (Please evaluate it.)

  1. Calculate all ranges that need to be deleted for each ImportDeclaration
  2. Merge conflicting ranges into a larger range through a sweeping algorithm
  3. When deleting a (Default) Specifier, delete the range calculated in step 2.

For ex)

import Unused1, { Unused2, Unused3 } from "foo";

If you want to quick fix for Unused2, expect

Copy link
Author

Choose a reason for hiding this comment

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

image
If I need to erase a larger range and a collision occurs, I may want to split the larger range.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting response Issues waiting for a reply from the OP or another party
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Enhancement: [no-unused-vars] add a default-off option to autofix remove unused imports
2 participants