fix(no-node-access): improve detection for Testing Library calls

[y-hsgw]

As suggested in this comment, I’ve implemented a resolveToTestingLibraryFn utility inspired by eslint-plugin-jest’s parseJestFnCall.

Checks

• I have read the contributing guidelines.

Changes

• Introduced resolveToTestingLibraryFn, which improves accuracy by accepting a CallExpression node and resolving where it comes into the file — in other words, tracing it back to its original import source. This follows the same principle used in eslint-plugin-jest's parseJestFnCall.
• I’ve also created an accessors.ts module that parseJestFnCall depends on. It’s largely traced from the original implementation in eslint-plugin-jest.
• Addressed one of the concerns raised in issue no-node-access rule output false-positive warning after 7.5.0 release #1024:
  • userEvent.setup() instances with custom variable names (not just user) are now recognized and excluded from being flagged incorrectly (e.g., const userEvt = userEvent.setup(); userEvt.click(...) is no longer a false positive).

I understand this PR is a bit large—if it would help with the review process, I'm happy to split it into smaller parts. Please let me know if you'd prefer that.🙇‍♂️

Context

Fixes #1024

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.49%. Comparing base (1c1497a) to head (8062770).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1033      +/-   ##
==========================================
+ Coverage   96.30%   96.49%   +0.18%     
==========================================
  Files          47       49       +2     
  Lines        2542     2679     +137     
  Branches     1051     1106      +55     
==========================================
+ Hits         2448     2585     +137     
  Misses         94       94              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Belco90]

@y-hsgw thanks! I'll try to review this during the week.

[Belco90]

I'm happy with the changes in general, but I'd like to think a bit more about the implications regarding the aggressive reporting.

[y-hsgw]

I've added preliminary support for testing-library/utils-module in 6781117.
I hope this helps as a reference for further discussion.
Please feel free to let me know if it doesn't align with your expectations — I'm happy to revert if needed 🙇‍♂️

[Belco90]

I've added preliminary support for testing-library/utils-module in 6781117. I hope this helps as a reference for further discussion. Please feel free to let me know if it doesn't align with your expectations — I'm happy to revert if needed 🙇‍♂️

Thanks, this is great! I think it's fine and shouldn't overlap with the aggressive reporting for now. I'll give it another go and let you know if I can think of any improvement.

In the meantime, codecov is complaining about decreased code coverage so you can add some tests to cover that.

[Belco90]

Great job adding the detection logic 👏! I believe we must merge the logic within create-testing-library-rule at some point, so the resolveToTestingLibraryFn is injected as a helper in the rule, but that's a nice-to-have.

There is still one case not handled: a custom render that already setup user-event.

import { render, screen } from 'my-tests-utils`
import MyComponent from './MyComponent'

test('should do whatever', () => {
  const { user } = render(<MyComponent />)
  //           ^--- user event instance is returned by the the custom render, which is imported from a custom file (not Testing Library module)
})

I think for this case, if we find user-event methods used that are coming from a variable (user in this case) from a render-like method, that it's imported from a valid testing module (Testing Library module or valid custom module per Aggressive Reporting), it should be fine.

However, this is a complex case, so it's fine merging this PR for now, and handle this complex case separately. First, we need to report user-event usages coming from custom testing util modules, then figure out how to assume the object returned by the render is a user-event instance.

[Belco90]

Let's add a comment to the ambiguous local module test, and should be ready to go! 🚀

[Belco90]

Amazing job 💪

[github-actions]

🎉 This PR is included in version 7.5.4 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[koju]

There is still one case not handled: a custom render that already setup user-event.

import { render, screen } from 'my-tests-utils`
import MyComponent from './MyComponent'

test('should do whatever', () => {
  const { user } = render(<MyComponent />)
  //           ^--- user event instance is returned by the the custom render, which is imported from a custom file (not Testing Library module)
})

@y-hsgw

The "render" configuration mentioned by @Belco90 is standard setup as per the userEvent docs.

The release >= 7.5.4 shows "no-node-access" error when using user.click(element) with above config.