Rules do not work with custom name library name

[stefcameron]

I love the no-debug rule, however, it doesn't work if you're using a custom local library name in order to, for example, provide a custom render function to the rest of your code.

I agree that the library name is no longer @testing-library/react, for example, and could be anything, so the rule doesn't find a match, but because customizing the render function is in the docs, and I presume quite standard practice, it makes this rule an immediate non-starter, which is a shame since the rule would be really nice to have.

Seems like the rule needs an option, similar to the existing renderFunctions option, that we can use to specify the name of our import. In my case, it's import ... from 'testingUtility'.

import { screen } from '@testing-library/react';
...
screen.debug(); // IS a lint error

however,

import { screen } from 'testingUtility';
...
screen.debug(); // is NOT a lint error -- and should be

[timdeschryver]

This probably affects most of the (all?) rules 😅

[Belco90]

Wow, didn't think about this before. @timdeschryver exactly, this can potentially affect all the rule. To solve this properly we would need to include a global param in the plugin config so you can set your custom module from where you import Testing Library stuff. Otherwise, we can't know if the screen you are importing is from Testing Library or not.

[nickserv]

Could we alternatively solve this without any config using some more dynamic logic?

[Belco90]

I don't know if it's possible to guess this from our ESLint component. I'll check how other libraries get this kind of dynamic values from custom user files.

[timdeschryver]

TIL, there are shared settings seems like something we can use? Not sure tho...

ESLint supports adding shared settings into configuration file. You can add settings object to ESLint configuration file and it will be supplied to every rule that will be executed. This may be useful if you are adding custom rules and want them to have access to the same information and be easily configurable.

[Belco90]

@timdeschryver Yes, that's the option I was thinking about. That's what I have to use for setting up eslint-plugin-import for example. Others like eslint-plugin-node can look for other files or settings, but I'm afraid we will have to do this with ESLint settings.

[nickserv]

What's the difference? I thought they all used the ESLint config.

[Belco90]

What's the difference between what? Sorry, I don't know what you mean. ESLint setting is just a key within ESLint config file.

[stefcameron]

I think ESLint Shared Settings, as @timdeschryver points out, would be a good way to go to solve this for all rules. Another example is eslint-plugin-react, see configuration options

[nickserv]

@stefcameron Ah yes, that is what I was thinking of, thanks

[stefcameron]

I also wanted to address a question about the use case I saw via email notification yesterday night, but can no longer find on this issue. Perhaps it was deleted, but I thought I would still clarify for posterity.

In my description of the issue, I mentioned the need for custom render functions, which is straight out of Testing Library documentation.

The documentation for the no-debug rule actually points to an example, which is an illustration of my use case, though not my exact use case (and also straight out of Testing Library docs): https://testing-library.com/docs/example-react-redux

My specific use case is related to using React context providers and the useContext hook. The concrete example is with Emotion Theming. The product I'm working on relies on the <ThemeProvider> to provide the theme object to any component.

The result is that nearly every component calls the useTheme() hook in some way or another, which means it cannot be rendered without being wrapped in <ThemeProvider>:

import { render, screen } from '@testing-library/react';
import { ThemeProvider } from 'emotion-theming';
import { lightTheme } from './themes';
import { Component } from './file';
...
it('should render', () => {
  render(
    <ThemeProvider theme={lightTheme}>
      <Component />
    </ThemeProvider>
  );
  expect(screen.getByRole('something')).toBeInTheDocument();
});

Therefore, I followed the example in the docs -- which happens to use a generic <ThemeProvider> 🙂 -- to "replace" the provided render() method with an enhanced version that wraps the component being tested with an instance of <ThemeProvider>.

I took it a step further and also configured Jest to remove the need to use crazy relative paths everywhere and just import ... from 'testingUtility';. So now my code becomes:

import { render, screen } from 'testingUtility';      // <- my local module that uses @testing-library/react internally
// * no need to import emotion-theming and themes
import { Component } from './file';
...
it('should render', () => {
  render(<Component />);                                      // <- much simpler!
  expect(screen.getByRole('something')).toBeInTheDocument();
});

Another advantage here is that if an additional context provider is needed later on, we can add it in one place (in testingUtility.js) and every single test suite will automatically get "upgraded" to use it.

So I think this is a very valid use case, especially since it's straight out of the Testing Library docs, and I think it should be supported, if possible.

[nickserv]

I deleted my comment originally because I forgot that you mentioned the custom render function, but this does help to add some more clarity to different use cases, thanks! Another idea is that you might need to adjust TypeScript types for passed props/context/etc. by wrapping the testing library functions in types with different interfaces (this used to be the way to provide themes to Styled Components before they implemented type augmentation).

Given all these use cases, I guess we do need a config. We would have to resolve the modules to search the dependency tree for testing libraries, and even with that you couldn't easily publish a fork. It would also be difficult to accurately determine whether a module is meant to replace testing library, or is just some testing utility that happens to import a method from it (in which case you wouldn't want your linter telling you to use functions from it that don't exist).

I still think there's another problem even with a custom config though: The module wrapping testing library would have to have the same API with the same semantics, otherwise rules might recommend the wrong methods, methods may not exist, or advice may not be relevant. I guess there isn't really a way around this beyond telling users to write their own custom ESLint rules (which you can do locally without publishing a separate package), so we might want to warn that these rules are only designed to be used with a wrapper that follows the same API and semantics, and possibly link to the ESLint docs for custom rules.