Thanks for the PR,@fisker!

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 onhttps://opencollective.com/typescript-eslint.

✅ Deploy Preview fortypescript-eslint ready!

Name	Link
🔨 Latest commit	1c6eae1
🔍 Latest deploy log	https://app.netlify.com/projects/typescript-eslint/deploys/69245dec246afd0008d81350
😎 Deploy Preview	https://deploy-preview-11591--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 85 (🔴 down 12 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 yourNetlify project configuration.

View yourCI Pipeline Execution ↗ for commit1c6eae1

☁️Nx Cloud last updated this comment at2025-11-24 13:53:17 UTC

Codecov Report

❌ Patch coverage is4.16667% with23 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.50%. Comparing base (78858ee) to head (1c6eae1).
⚠️ Report is 3 commits behind head on main.

❌ Your patch status has failed because the patch coverage (4.16%) is below the target coverage (90.00%). You can increase the patch coverage or adjust thetarget coverage.

@@            Coverage Diff             @@##             main   #11591      +/-   ##==========================================- Coverage   90.52%   90.50%   -0.02%==========================================  Files         522      522                Lines       53353    53366      +13       Branches     8921     8920       -1     ==========================================+ Hits        48296    48300       +4- Misses       5040     5050      +10+ Partials       17       16       -1

Cherry-picked fix for#11593 (comment), hope the test will pass.

Strange, this was released, but not mentioned in the changelog.6fb1551

Did I use the wrongfix(typescript-estree)?

> require('@typescript-eslint/typescript-estree').parse('type a = import("a")').body[0].typeAnnotation{  type: 'TSImportType',  options: null,  qualifier: null,  source: { type: 'Literal', raw: '"a"', value: 'a' },  typeArguments: null}> require('@typescript-eslint/typescript-estree').parse('type a = import("a")').body[0].typeAnnotation.argument{  type: 'TSLiteralType',  literal: { type: 'Literal', raw: '"a"', value: 'a' },  range: [ 16, 19 ],  loc: { end: { column: 19, line: 1 }, start: { column: 16, line: 1 } }}

Hmm, the PR title should be correct. Maybe it's an issue with changelog generation?

Also, we are supposed to make this a non-breaking change, but it breaks eslint-plugin-unicorn,sindresorhus/eslint-plugin-unicorn#2829 (comment)

I think that's because we removedargument from visitor keys. Unicorn is fine with this, but I don't know if other plugin will be broken.

How do we usually do with deprecated property? Keep or remove?

First guess without looking into it deeply is that the commit body wasn't cleaned up before merging, it looks a little whacky with those revert commit references:

Yeah that's it. We detect reverted hashes present in a commit in order to determine if a change was merged and reverted within the same release and can therefore strip it so that it isn't noise on the changelog.

Because there are reverted references in the commit body, the overall change gets classed as a revert, which is hidden from the changelog

I don't think there is any way for the release tooling to differentiate these scenarios, sadly I think it's down to maintainers to ensure the commit bodies are clean before merging. Tbh I always nuke the entire body when I squash merge...

Revert commits during the lifecycle of a PR are a bit more of an uncommon thing in my experience, so I think that's why this specific case hasn't come up before.

But yeah, overall those revert references have zero value for posterity because they were reverts of commits within a deleted PR branch, so I think the ultimate solution here is to make sure they are cleaned up on merge (SO wish GitHub had added squash merge validation hooks by now, it's been so long)