fix(eslint-plugin): [consistent-type-imports] dont report on types used in export assignment expressions

[auvred]

PR Checklist

• Addresses an existing open issue: fixes Bug: [consistent-type-imports] erroneous report on type used in an export = assertion #8330
• That issue was marked as accepting prs
• Steps in Contributing were taken

Overview

I missed that in #8265 :

In cases like export = {} as T, T was referenced as isTypeReference: true and isValueReference: true. Now it's only referenced as a type

[typescript-eslint]

Thanks for the PR, @auvred!

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.

[netlify]

✅ Deploy Preview for typescript-eslint ready!

Name	Link
🔨 Latest commit	de9754f
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/65bb6a0bf5a88d0008a3099c
😎 Deploy Preview	https://deploy-preview-8332--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 87 (🔴 down 3 from production) Accessibility: 100 (no change from production) Best Practices: 92 (no change from production) SEO: 98 (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 site configuration.

[codecov]

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (d805516) 87.71% compared to head (de9754f) 87.70%.
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8332      +/-   ##
==========================================
- Coverage   87.71%   87.70%   -0.02%     
==========================================
  Files         397      397              
  Lines       13948    13950       +2     
  Branches     4054     4055       +1     
==========================================
  Hits        12235    12235              
- Misses       1401     1403       +2     
  Partials      312      312              

Flag	Coverage Δ
unittest	87.70% <66.66%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
...eslint-plugin/src/rules/consistent-type-imports.ts	95.28% <ø> (ø)
...ages/scope-manager/src/referencer/ExportVisitor.ts	90.90% <100.00%> (-0.76%)	⬇️
...ackages/scope-manager/src/referencer/Referencer.ts	95.56% <100.00%> (+0.03%)	⬆️
...internal/src/rules/no-typescript-default-import.ts	88.23% <0.00%> (-11.77%)	⬇️

[bradzacher]

Thanks for hopping on this so fast!

I believe here should be no change required to the rule here - just a fix to the scope analysis. The tests are correct to add though!

Given the export equals declaration accepts an expression - we don't want to drop down into the export visitor. We just need a special case for the one special case - the identifier case. All other cases can be handled as a normal expression would.

In the identifier case we can immediately create a dual-reference. We know it's just this case because both T[U] and T.U are semantic errors from TS if T is a type, or T.U is a type (any syntactically those are the two valid ways to "chain" off a type reference).

[bradzacher]

brilliant - thanks!