Thanks for the PR,@Tamashoo!

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	493c1b2
🔍 Latest deploy log	https://app.netlify.com/projects/typescript-eslint/deploys/6929dafd3c9c1100079fa93a
😎 Deploy Preview	https://deploy-preview-11766--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 93 (🔴 down 5 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 commit493c1b2

☁️Nx Cloud last updated this comment at2025-11-28 17:37:46 UTC

There are two small issues ATM :)

1. should perform the value check during iteration, since there may be multi re-export, e.g

   // a.tsexporttypeA=1// b.tsimport{A}from'./a'constA=1export{A}// c.tsexport{A}from'./b'// false positive

2. need to handlenamespace case, e.g

   // a.tsexporttypeA=1// b.tsimport{A}from'./a'namespaceA{exportconstb=2}export{A}

I'd personally prefer checkingSymbolFlags.Value, looks simpler and robust. However, I'm not entirely sure if it covers all cases. 😅

@JoshuaKGoldberg
Thank you for reviewing!
My understanding is that you only need to merge one of the pull requests.
Looking at#11769, it seems more efficient than this PR.

@ntdiary
According to your comment, should we add these test cases in this time, or in a separate one?

Thanks

@ntdiary According to your comment, should we add these test cases in this time, or in a separate one?

Eh, for now, I don't feel strongly about adding thoseedge cases :), mainly because:

1. the tests I added already cover the regular cases and show that the rule works well.
2. I'm exploring@typescript/vfs, which might change how to write multi-file test (not sure how it'll turn out or whether it'll be accepted, but it seems worth trying first)

I'll go ahead and merge#11769 tomain, as the approach is a bit more direct - then add in the added test cases from this PR.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.49%. Comparing base (bb9ba53) to head (493c1b2).
⚠️ Report is 3 commits behind head on main.

@@           Coverage Diff           @@##             main   #11766   +/-   ##=======================================  Coverage   90.49%   90.49%           =======================================  Files         522      522             Lines       53362    53367    +5       Branches     8913     8918    +5     =======================================+ Hits        48288    48293    +5  Misses       5059     5059             Partials       15       15

Thanks@Tamashoo@ntdiary for working on these two PRs & the good discussion around them!