Thanks for the PR, @MariaSolOs!

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.

✅ Deploy Preview for typescript-eslint ready!

Name	Link
🔨 Latest commit	2615be3
🔍 Latest deploy log	https://app.netlify.com/projects/typescript-eslint/deploys/697a859bf1a6d500085b2b46
😎 Deploy Preview	https://deploy-preview-11990--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 72 (🔴 down 21 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 your Netlify project configuration.

View your CI Pipeline Execution ↗ for commit 2615be3

☁️ Nx Cloud last updated this comment at 2026-01-28 22:02:13 UTC

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.80%. Comparing base (d50aa18) to head (2615be3).
⚠️ Report is 17 commits behind head on main.

@@            Coverage Diff             @@
##             main   #11990      +/-   ##
==========================================
+ Coverage   90.78%   90.80%   +0.01%     
==========================================
  Files         530      531       +1     
  Lines       54402    54637     +235     
  Branches     9196     9228      +32     
==========================================
+ Hits        49391    49611     +220     
- Misses       4998     5015      +17     
+ Partials       13       11       -2     

leaves blank lines when removing the entire import statement

As much as I dislike leaving blank lines around, I don't think this is in the scope of what we'd want to add a lot of code to handle? Detection/practices around blank lines are not in the purview of the rule. The general project stance is that if folks care about that, they should use a separate tool: preferably (to us) a dedicated formatter, or alternately a dedicated lint rule.

If this PR was just a couple lines it'd be a lot more palatable. But at >30 lines, although I appreciate the work that went into it, I don't think we'd want to take on that maintenance burden.

@JoshuaKGoldberg I understand. I do want to mention that before this fixer was added I was using eslint-plugin-unused-imports, which does handle this edge case with blank lines. I do prefer the built-in fixer, but this feature is something that I miss from the other plugin.

they should use a separate tool: preferably (to us) a dedicated formatter, or alternately a dedicated lint rule.

I agree that whitespace should preferably be always handled with formatters, but in this specific case a tool like Prettier won't remove the new blank line (it just enforces that there are no multiple lines between imports). Moreover lint rules like import/order can be configured to prohibit blank lines between import groups, which conflict with the modifications of this fixer.

Detection/practices around blank lines are not in the purview of the rule.

I again agree with you here, but intuitively I think that the least "disruptive" modification when removing an import statement is to remove the new line.

@MariaSolOs this would require an issue first in order to be considered. It's a nontrivial PR for an ordinary feature that doesn't fall under the "minor documentation changes" exception; see https://typescript-eslint.io/contributing/pull-requests

Marking as draft for now, pending issue acceptance.

@kirkwaiblinger fair enough, my bad for not following the right order here. Issue created: #11996

Hmm not sure why the CI checks were cancelled...

This approach should work.

An alternate approach might be to use tokens:

1. get the token (incl comments) before the import decl

   1. if it's on the same line then the decl is not on its own line
   2. else it's on its own line and and set delete start to prevToken.range[1]

2. get the token (incl comments) after the import decl

   1. if it's on the same line then the decl is not on its own line
   2. else it's on its own line and and set delete start to nextToken.range[0]

That would let us guarantee that we can delete extra whitespace (which is a nice benefit).

There are two edge cases to handle with this though:

1. if the import decl is the first statement in the file
2. if the import decl is the last statement before non-decls

IDK if this is better than your current approach.. probably not due to the edge cases?

1 extra test and I think we're probably good to go?

Yeah because of edge cases I think this is as pretty as it gets.

I'm happy with this as-is. The token approach sounds fine to me too so feel free to go with that but it looks like it'll just be a bit longer since you have to do the same wrangling of the edge case when there's no next line 🤷‍♂️

Thanks for sending this PR!

Thanks to you for all the feedback! Is always a pleasure to contribute to this project :)