Rule proposal: prefer-t-regex

[sindresorhus]

Users should prefer the regex assertion as it's more readable and gives better output.

Fail

t.true(/\d+/.test(foo()));

Pass

t.regex(foo(), /\d+/);

Same for the negated ones, with t.notRegex.

---

Would also be useful to be able to detect the regex from a variable somewhere else in the scope as I often share a regex between multiple asserts:

const re = /\d+/;

…

t.true(re.test(foo()));

---

This could be auto-fixable, right?

---

Should we also detect the following?

t.true(foo().search(/\d+/));
t.truthy(foo().match(/\d+/));

IssueHunt Summary

gmartigny has been rewarded.

Sponsors (Total: $60.00)

• issuehunt ($60.00)

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

[jfmengels]

Sounds good to me 👍
This sounds auto-fixable yes.

In the case of t.true(re.test(foo()));, I would think that .test() inside a t.true() call is a sign of a regex, so I think we can report it. Maybe not auto-fix it for safety's sake.

Should we also detect the following?

t.true(foo().search(/\d+/));

Didn't know this API 🤔

t.truthy(foo().match(/\d+/));

For both of these, if they have regexes as the sole argument, I'd say yes. For match, I'd personnally even like it if got autofixed to .test() and t.true

[sindresorhus]

For match, I'd personnally even like it if got autofixed to .test() and t.true

Huh? Why not t.regex()?

[jfmengels]

Ha, yes, that's better obviously 😅

[IssueHuntBot]

@IssueHunt has funded $60.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[IssueHuntBot]

@sindresorhus has rewarded $54.00 to @GMartigny. See it on IssueHunt

• 💰 Total deposit: $60.00
• 🎉 Repository reward(0%): $0.00
• 🔧 Service fee(10%): $6.00