fix(prefer-in-document): handle toHaveLength without any arguments and with trailing commas

[berkinanik]

What:

1. For toHaveLength:

• Calling toHaveLength without any arguments causing .value on undefined object fixed.
• if no argument provided, toHaveLength(), it is also considered as toHaveLengthZero together with toHaveLength(0).

2. matcherArgument removal logic in eslint fixer is updated to remove the commas also, if there were multiple args in the matcher.

Why:

1. toHaveLength method on expect is causing eslint to crash since no argument logic isn't handled properly in the prefer-in-document rule. If eslint is always watching and linting live, this issue is quite annoying.

Eslint plugin crush stack trace in VSCode:

Even after handling calling toHaveLength without any arguments, it won't work since toHaveLength expected argument is required. Thus, toHaveLength without any arguments considered as toHaveLength zero.

2. toHaveLength(0) and toHaveLength(1) on a RTL query replaced to proper toBeInTheDocument's. Logic is already applied to work with multiple arguments but, if there were multiple arguments after 0 or 1, commas aren't removed.

How:

1. to fix eslint crashing issue (.value on undefined in matcherArguments[0].value): empty arg array is handled properly.

(matcherArguments.length === 0 || matcherArguments[0].value === 0)

2. while removing arguments following lines added to remove commas also:

const sourceCode = context.getSourceCode();
const token = sourceCode.getTokenAfter(argument);
if (token.value === "," && token.type === "Punctuator") {
  // Remove commas if toHaveLength had more than one argument or a trailing comma
  operations.push(fixer.replaceText(token, ""));
}

Checklist:

• Documentation
• Tests
• Ready to be merged
  

Fixes #277

[G-Rath]

A better fix for this should be to use the starting location of the first argument and then the ending location of the last argument - that way we don't have to actually care about the commas at all.

[berkinanik]

You might me right, I thought about it also (couldn't tried since I don't know the working mechanism of the eslint very well),
but I felt like comments would create problems if we handled it that way

[G-Rath]

Problems with comments are not something we can really avoid - I'm happy to pick up getting the PR landed if you've not got the bandwidth :)

[berkinanik]

that would be great, thanks 🙂

[G-Rath]

ok so I was thinking about the handing for another situation (ESLint fixers are a bit mystic because of all the different ways code can be shaped 😂) - what you've got is good; it also turns out we're not handling trailing commas properly in eslint-plugin-jest either so thanks for being this to my attention!

[codecov]

Codecov Report

Merging #276 (92ba227) into main (4299024) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main      #276   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           15        15           
  Lines          575       581    +6     
  Branches       165       167    +2     
=========================================
+ Hits           575       581    +6     

Impacted Files	Coverage Δ
src/rules/prefer-in-document.js	100.00% <100.00%> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[github-actions]

🎉 This PR is included in version 4.0.3 🎉

The release is available on:

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

Your semantic-release bot 📦🚀