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

importx= require('foo')

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

Oh, nice catch. This isTSImportEqualsDeclaration 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

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

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

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 usenoFormat):

importxfrom'foo';importyfrom'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).

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

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

related commit:2c8b740 &9a15d49

This logic assume that unusedVariables collected sequentially from the code.
Deductively, it works fine.
But, I'm not really sure if that's true in all cases.

constanalysisResults=collectVariables(context);constvariables=[        ...Array.from(analysisResults.unusedVariables,variable=>({used:false,          variable,})),        ...Array.from(analysisResults.usedVariables,variable=>({used:true,          variable,})),];

[Bug] This is specific to imports, so we should be more specific here I think.

[Style] A few interlinked suggestions:

• This comment doesn't add anything IMO: the variable is already named "unused import specifiers", and its type says that import declarations are the keys
• TheMap suffix in the name isn't necessary either - it's a map type already
• It's kind of confusing to read through so much new logic, where a few dozen lines are just to populate a map. Let's move the logic into a function outside of the rule.

Moving#11243 (review) &#11243 (comment) into a thread:

yes, it is not supported. When handling this, a conflict occurs in the range that the fixer removes, and is therefore ignored.

Just to confirm what it looks like the implementation went with: conflicts are ok! ESLint runs up to 10 passes of auto-fixing. If there are 2-3 fixes in a range and only 1-2 get applied in a time, that's fine. It'll get all of them eventually. Fixes are by design meant to always improve codebase quality. They never backtrack.

Okay. Then, I think I can just delete the complex (conflict-causing) test case and the logic surroundingthis comment (this will greatly simplify the overall logic).
I'll wait for other people's opinions.