You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue tracks the progress of providing auto-fix suggestions for eslint/no-unused-vars. All auto-fixes will be "dangerous suggestions", so oxlint will need to be run with --fix-suggestions --fix-dangerously for them to be applied.
Prerequisites
Tasks that adding auto-fixing depends on but that aren't directly related to its implementation
fix(linter/no-unused-vars): symbol spans should not include type annotations
test(linter): test expected fixes by FixKind
feat(linter): add maybeAsiHazard to RuleFixer
NOTE: this one is also needed for no-console
Unsolved Problems
1. Symbols to Never Remove
IMO, there are some symbols that should never be removed. A (non-comprehensive) list would be
Classes
Functional React components
Interfaces
Namespaces
Function statements
Are there symbol kinds that should be added to or removed from this list? Would love some opinions.
2. Declaration Lists
How should we handle removing unused VariableDeclarations and ImportStatements that declare multiple symbols?
Right now fixers are a fixes are applied independently of each other. However, if all imports are unused, and each diagnostic only deletes the symbol its reporting, then this:
import{A,B}from'./a'
Would be fixed into:
import{}from'./a'
Making this fix delete the import statement entirely would change program behavior if ./a has side effects. I would love to hear opinions on this.
3. Unused Reference Chains
A read reference is considered a usage even if it's being used by a variable that is itself unused. This means that when this code gets auto-fixed:
typeT=number// used by aconsta: T=4// not used anywhere
it will become
typeT=number// now T is unused!
I'd expect T to also be removed here, but it remains.
4. JSDoc-only Imports
Sometimes people import things for use in JSDoc comments. Removing them would break their documentation
We could force this to be a type-only import, and then never remove them
importtype{Relevant}from'./foo'
We could add JSDoc references to Semantic and consider that a usage
We could update no-unused-vars to look through extracted JSDoc @links and derive usage manually
Suggestions
1. Variable Declarations
Remove variable declarations with no references of any kind
If a varsIgnorePattern is provided, try to rename the variable to match it
Do not delete declarators whose initializers contain assignment expressions to other symbols js // x is unused, but we don't wanna delete the whole statement since it removes the export const foo = module.exports = function foo() {}
2. Imports
Sometimes people import things for use in JSDoc comments. Removing them
Delete unused named imports
Delete unused default imports
Delete import * as x imports
CC: @oxc-project/linter
The text was updated successfully, but these errors were encountered:
This issue tracks the progress of providing auto-fix suggestions for
eslint/no-unused-vars
. All auto-fixes will be "dangerous suggestions", sooxlint
will need to be run with--fix-suggestions --fix-dangerously
for them to be applied.Prerequisites
FixKind
maybeAsiHazard
toRuleFixer
Unsolved Problems
1. Symbols to Never Remove
IMO, there are some symbols that should never be removed. A (non-comprehensive) list would be
Are there symbol kinds that should be added to or removed from this list? Would love some opinions.
2. Declaration Lists
How should we handle removing unused
VariableDeclaration
s andImportStatement
s that declare multiple symbols?Right now fixers are a fixes are applied independently of each other. However, if all imports are unused, and each diagnostic only deletes the symbol its reporting, then this:
Would be fixed into:
Making this fix delete the import statement entirely would change program behavior if
./a
has side effects. I would love to hear opinions on this.3. Unused Reference Chains
A read reference is considered a usage even if it's being used by a variable that is itself unused. This means that when this code gets auto-fixed:
it will become
I'd expect
T
to also be removed here, but it remains.4. JSDoc-only Imports
Sometimes people import things for use in JSDoc comments. Removing them would break their documentation
Semantic
and consider that a usageno-unused-vars
to look through extracted JSDoc@link
s and derive usage manuallySuggestions
1. Variable Declarations
varsIgnorePattern
is provided, try to rename the variable to match itjs // x is unused, but we don't wanna delete the whole statement since it removes the export const foo = module.exports = function foo() {}
2. Imports
Sometimes people import things for use in JSDoc comments. Removing them
import * as x
importsCC: @oxc-project/linter
The text was updated successfully, but these errors were encountered: