Skip to content

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

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
4 tasks done
bradzacher opened this issue May 16, 2025 · 1 comment
Open
4 tasks done
Labels
accepting prs Go ahead, send a pull request that resolves this issue enhancement: plugin rule option New rule option for an existing eslint-plugin rule package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin

Comments

@bradzacher
Copy link
Member

bradzacher commented May 16, 2025

Before You File a Proposal Please Confirm You Have Done The Following...

My proposal is suitable for this project

  • I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Link to the rule's documentation

https://typescript-eslint.io/rules/no-unused-vars/

Description

Currently all no-unused-vars errors are not fixable. This is for good reasons, eg:

  • side-effects are possible nearly everywhere in JS and it's impossible for us to know if an expression has a side-effect
  • unused variables are a common part of the developer workflow and many people use autofix-on-save in their IDE -- so a fixer would cause "soon to be used" variables from being auto-deleted accidentally (an obviously frustrating DevX!)

With that being said there is one subset of unused variables which are generally safe to autofix -- imported names. These are generally safe to fix because:

  • the vast, vast, vast majority of modules do not have top-level side-effects
    • most bundlers and minifiers run on the assumption that modules DO NOT have side-effects!
  • imports are mostly managed by the IDE (eg an IDE will auto-add import on usage of imported thing) and so removing a "soon to be used" import generally is low-impact from DevX.

There's evidence that the community wants this -- for example eslint-plugin-unused-imports exists and is pretty widely used (they have ~8.4% of our weekly downloads). This plugin introduces two rules -- both are just monkey-patched extension rules on top of our no-unused-vars implementation where one rule only reports on variables and the other only reports on imports and provides a fixer.

My proposal is the following:

  1. add a new option, say enableAutofixRemoval: { imports: boolean } with default enableAutofixRemoval: { imports: false } (i.e. disable the autofixer by default).
  2. build an autofixer for imported names that does the following:
    1. if the unused name is a namespace import, remove the entire import declaration.
    2. if the unused name is a default import:
      1. if there are no used named imports in the declaration, remove the entire import declaration.
      2. if there are used named imports in the declaration, just remove the unused default import.
    3. if the unused name is a named import:
      1. if there are no other used names in the declaration, remove the entire import declaration.
      2. if there are used names in the declaration, just remove the unused named import.
  3. if enableAutofixRemoval.imports === true
    1. then set the fixer from (2) as an auto-fixer
    2. else set the fixer from (2) as a suggestion fixer

Additional Info

Namespace:

import * as Unused from 'foo';
import * as Used from 'foo';

export { Used };

autofixes to:

import * as Used from 'foo';

export { Used };

Default:

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

export { Used };

autofixes to:

import { Used } from 'foo';

export { Used };

Named:

import { Unused1 } from 'foo';
import Used1, { Unused2 } from 'foo';
import { Unused3, Used2 } from 'foo';
import Used3, { Unused4, Used4 } from 'foo';

export { Used1, Used2, Used3, Used4 };

autofixes to:

import Used1 from 'foo';
import { Used2 } from 'foo';
import Used3, { Used4 } from 'foo';

export { Used1, Used2, Used3, Used4 };
@bradzacher bradzacher added package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin triage Waiting for team members to take a look enhancement: plugin rule option New rule option for an existing eslint-plugin rule labels May 16, 2025
@JoshuaKGoldberg
Copy link
Member

👍 This isn't the first time that a specific rule suggestion deserves an option to switch to a fix. It'd be nice if this could be mainlined into ESLint...

@JoshuaKGoldberg JoshuaKGoldberg added accepting prs Go ahead, send a pull request that resolves this issue and removed triage Waiting for team members to take a look labels May 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepting prs Go ahead, send a pull request that resolves this issue enhancement: plugin rule option New rule option for an existing eslint-plugin rule package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin
Projects
None yet
Development

No branches or pull requests

2 participants