no-node-access rule output false-positive warning for FireEvent after 7.5.4

[pstachula-dev]

Have you read the Troubleshooting section?

Yes

Plugin version

7.5.4

ESLint version

9.30.1

Node.js version

22.14

Bug description

False positive error for fireEvent from:
import { fireEvent } from '@testing-library/react';

Steps to reproduce

1. Bump eslint-plugin-testing-library from 7.5.3 to 7.5.4

Error output/screenshots

ESLint configuration

  {
    files: ['**/*.test.{ts,tsx}'],
    ...pluginTestingLibrary.configs['flat/react'],
  },

Rule(s) affected

no-node-access

Anything else?

No response

Do you want to submit a pull request to fix this bug?

No

[y-hsgw]

I tried reproducing it locally using the same version, but I couldn't reproduce the issue 😢
Also, as shown in the following test case, I believe that usage of fireEvent should already be supported:

eslint-plugin-testing-library/tests/lib/rules/no-node-access.test.ts

Lines 214 to 221 in 7812dae

	{
	code: `
	import { screen, fireEvent as fe } from '${testingFramework}';
	const buttonText = screen.getByText('submit');
	fe.click(buttonText);
	`,
	},

Would it be possible for you to share a sample code snippet or a link to the relevant repository instead of a screenshot?

[pstachula-dev]

Ok, so I will create reproduction repo

[pstachula-dev]

@y-hsgw I found the issue - very wierd.

https://stackblitz.com/edit/vitejs-vite-wqratcpq?file=src%2Fexample.test.tsx,eslint.config.mjs,package.json,src%2Fcustom-render.tsx&terminal=dev

tldr:

• when I use re-export pattern with custom-render, then I have errors

import { fireEvent, screen } from './custom-render';
// import { fireEvent, screen } from '@testing-library/react';

it('should fetch users with Authorization header', async () => {
  fireEvent.click(screen.getByTestId('fetch-users-btn'));
});

[Belco90]

@pstachula-dev thanks for reporting. It seems the new Testing Library resolver is colliding already with the Aggressive Reporting.

@y-hsgw I think if the util is not considered as a Testing Library resolver, we should apply some Aggressive Reporting assumptions with the default Testing Library util names. What do you think?

[dleung107]

I'm seeing a similar issue with userEvent but only if the user object is created in the before each.

Eslint Error:

import {screen} from '@testing-library/react';
import userEvent from '@testing-library/user-event';

describe('Testing', () => {
  let user;

  beforeEach(() => {
    user = userEvent.setup();
  });

  it('test 1', async () => {
    await user.click(screen.getByRole('button'));
  });
});

No Eslint Error:

import {screen} from '@testing-library/react';
import userEvent from '@testing-library/user-event';

describe('Testing', () => {
  it('test 1', async () => {
    const user = userEvent.setup();
    await user.click(screen.getByRole('button'));
  });
});

[rdamazio]

I'm seeing exactly what @dleung107 reported too.

Example CI failure if you want something concrete: https://github.com/rdamazio/efis-editor/actions/runs/16232609553/job/45838131796?pr=247

[y-hsgw]

@Belco90
I might not have fully understood the comment, but I believe the main issue here is that resolveToTestingLibraryFn doesn't currently support Aggressive Reporting properly.
For example, cases with relative imports aren’t handled correctly 😢
(Sorry, at the time of that comment, I was mistakenly thinking that relative paths weren’t supported.)

I think we can fix this by adjusting the logic to follow what's done in detect-testing-library-utils, particularly around this part:

eslint-plugin-testing-library/lib/create-testing-library-rule/detect-testing-library-utils.ts

Lines 963 to 966 in 7812dae

	const hasImportModuleMatch =
	/testing-library/g.test(importDeclarationName) ||
	(typeof customModuleSetting === 'string' &&
	importDeclarationName.endsWith(customModuleSetting));

[AlexKrupko]

The same issue after upgrading to 7.5.4. It warns on userEvert.click returned from the custom render function

test('....', async () => {
    const {userEvent} = render(....);
    // ..... 
    await userEvent.click(element);
});