Lint RenderResult when returned from function

[HaveSpacesuit]

When returning a RenderResult from a function, some destructured methods are caught by the linter, but others aren't.

it('displays a loader', () => {
  const { getByText, debug } = render(<MyLoader />);
  getByText('Loading'); // Caught by linter
  debug(); // Caught by linter
});

it('displays a loader', () => {
  function renderLoader(): RenderResult {
    return render(<MyLoader />);
  }

  const { getByText, debug } = renderLoader();
  getByText('Loading'); // Caught by linter
  debug(); // Linter doesn't care
});

[Belco90]

Hey Eric! Thanks for opening an issue. It seems some rules are not checking properly those methods if not coming directly from testing library.

[timdeschryver]

Which rule is this? 👀
I'm thinking this is prefer-presence-queries, and it expect queries to be used from screen.
Imho this is correct.

[Belco90]

Well, the comment in the original description code indicating something not being linted is a debug method. I guess this refers to no-debug rule. @HaveSpacesuit please correct me if I'm wrong.

[timdeschryver]

Oh my bad, I miss-read the snippet.

[thomaslombart]

I'm not sure that's a bug. @HaveSpacesuit, have you tried setting up the renderFunctions option when configuring the no-debug rule?

You can do it this way:

rules: {
  "testing-library/no-debug": ["error", { "renderFunctions": ["renderLoader"] }],
}

If the getByText query is caught by the linter in the renderLoader example, it's probably because of the prefer-screen-queries rule.

[Belco90]

I think this one should be fixed when #198 is released.

[HaveSpacesuit]

The "testing-library/no-debug": ["error", { "renderFunctions": ["renderLoader"] }] rule doesn't seem to make any difference. The getByText is caught with the prefer-screen-queries rule whether or not it is destructured directly from render or from a function returning RenderResult, but the no-debug rule is not caught.

[Belco90]

Everything related to custom error render methods will change and should be fixed when #198 is released with v4.

[Belco90]

This should be fixed on v4.0.0

The release is available on:

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