Thanks for the PR, @nayounsang!

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 failed.

View your CI Pipeline Execution ↗ for commit 6fafc22

☁️ Nx Cloud last updated this comment at 2025-07-21 08:08:03 UTC

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.86%. Comparing base (3f58afe) to head (6fafc22).
Report is 5 commits behind head on main.

@@           Coverage Diff           @@
##             main   #11272   +/-   ##
=======================================
  Coverage   90.86%   90.86%           
=======================================
  Files         503      503           
  Lines       51036    51030    -6     
  Branches     8424     8416    -8     
=======================================
- Hits        46373    46368    -5     
  Misses       4648     4648           
+ Partials       15       14    -1     

This PR has the effect that the following code is flagged (with checkVoid enabled)

declare const maybeVoid: void | { x: () => { some: 'object' } };
maybeVoid && maybeVoid.x();

I'm not sure that that's what we want? I'd say instead the goal is that a void-returning function call at the end of a chain whose return value isn't used should be reported regardless of the check* options.

In other words, as far as implementation - we're not looking to include possibly-void values in checked chains except as the type of a function call at the end of the chain. It's not obvious to me that we need to create an option at all for this...

WDYT?

I've realized — I think this is a much more general bug. The check* options should not apply to the right hand side member of a chain. Only the left member. That is to say,

declare const x: { a: string };

// checkString: true
const y = x && x.a; // correctly reports

// checkString: false
const y = x && x.a; // (BUG) doesn't report

So, if we generally fix the logic so that the type checking only applies to the LHS of a potential chain expression x?.a, that should also automatically fix the reported bug regarding x?.a() as a special case.

Then, I guess we can check it except for right most. I will finish the work on void and reply.

After thinking about it further with comments and usage examples, I think the checkVoid option is not necessary. checkXXX is useful when there is an accessible method. When considering real-world usage, I couldn't think of a case where checkXXX would be used for void.

Oh, sorry. I misunderstood your review. Now I know what to do
I'll revert all of changes because, I changed so much and produce unnecessary codes.
Then, applying the logic to check except most RHS, I will focus on whether the issue case passes.
And if there is any problem, I will ask you. Thank you.

Hey @nayounsang — is this ready for another review pass? If so, we ask that you request review in the GUI so we know to take another look. If not, take your time and don't mind me! Just looked like it might be ready for another pass. Thanks!