Failure to Detect no-node-access Error Upon Re-Export of '@testing-library/react'

[y-hsgw]

Have you read the Troubleshooting section?

Yes

Plugin version

6.0.0

ESLint version

8.47.0

Node.js version

18.16.0

package manager and version

9.7.1

Operating system

macOS Ventura 13.4.1（22F82）

Bug description

Following the instructions in the custom-render section, I have created a test-utils.ts file and re-exported '@testing-library/react' within it to utilize the API of '@testing-library/react'. However, it seems that the ESLint plugin's ability to detect the "no-node-access" error becomes inconsistent when using imports from '@testing-library/react'.

test-utils.ts

import { ThemeProvider } from '@mui/material';
import { RenderOptions, render } from '@testing-library/react';

const AllTheProviders: React.FC<{ children: React.ReactNode }> = ({ children }) => (
  <ThemeProvider theme={theme}>{children}</ThemeProvider>
);

const customRender = (ui: React.ReactElement, options?: Omit<RenderOptions, 'wrapper'>) =>
  render(ui, { wrapper: AllTheProviders, ...options });

export * from '@testing-library/react';
export { customRender as render };

2023-08-17.21.36.53.mov

Steps to reproduce

1. Create a test-utils.ts file as directed in the custom-render section.
2. Inside the test-utils.ts file, export '@testing-library/react' and utilize its APIs.
3. Observe the ESLint behavior regarding the "no-node-access" error when using imports from '@testing-library/react' within this context.

Error output/screenshots

No response

ESLint configuration

{
  "extends": [
    "next/core-web-vitals",
    "plugin:@typescript-eslint/recommended",
    "prettier"
  ],
  "rules": {
    "prefer-template": "error"
  },
  "overrides": [
    {
      "files": ["*.test.{ts,tsx}"],
      "extends": ["plugin:jest/recommended", "plugin:testing-library/react"]
    }
  ]
}

Rule(s) affected

  "overrides": [
    {
      "files": ["*.test.{ts,tsx}"],
      "extends": ["plugin:jest/recommended", "plugin:testing-library/react"]
    }
  ]

Anything else?

No response

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

No

[Belco90]

Hi @y-hsgw. This behavior is intended, let me elaborate on this.

This rule is pretty aggressive itself, so we got an issue about limiting the errors reported about it #334. In #338 we limited the scope of the rule so errors are reported only if an actual Testing Library module or a explicit custom one are found. You can read more about it in this comment within the code.

You can fix it by declaring @/test/test-utils in the utils-module setting. We probably need to explain this in the rule's doc itself, so it's not hidden in the code itself.

Additionally, we could extend this rule to provide an option to restrict the scope of the errors reported or not (enabled by default).

[y-hsgw]

Hi @Belco90.

Thank you so much for your response. Your provided information helped me resolve the issue. Your detailed explanation was incredibly helpful and I truly appreciate it.

Thank you again for taking the time to reply amidst your busy schedule.