feat: create prefer-to-be-for-literals

[G-Rath]

Resolves #801

I'm open to bikeshedding on the name:

• prefer-to-be - we've already had a rule named this, but maybe thats ok?
• prefer-to-be-for-literals - a little wordy, arguably a little inaccurate
• prefer-to-be-for-primitive-literal - wordier, but the most accurate

I think this could be good to have in styles config when it comes time to do our next major.

[SimenB]

I like it!

[LitoMore]

We should support all literal types, such as null, undefined, and NaN.

And make its API defaults to:

'jest/prefer-to-be-for-literals': ['error', {
 	types: ['number', 'string', 'boolean']
}]

Its full API:

'jest/prefer-to-be-for-literals': ['error', {
 	types: ['number', 'string', 'boolean', 'undefined', 'null', 'NaN']
}]

What do you think?

[razh]

There's already toBeNull() and toBeUndefined(), the former of which is included as a valid case:

eslint-plugin-jest/src/rules/__tests__/prefer-to-be-for-literals.test.ts

Lines 7 to 9 in c5a389d

	valid: [
	'expect(null).toBeNull();',
	'expect(null).not.toBeNull();',

They're handled by the prefer-to-be-null and prefer-to-be-undefined rules.

I assume that NaN already counts as a primitive literal? Please correct me if I'm wrong!

[LitoMore]

Another brainstorm:

Deprecate prefer-to-be-null and prefer-to-be-undefined.

Use a new rule prefer-to-be instead, and make its API to:

'jest/prefer-to-be': ['error', {
  types: ['number', 'string', 'boolean', 'undefined', 'null', 'NaN']
}]

prefer-to-be-null, prefer-to-be-undefined, prefer-to-be-literals are doing the same thing, we could combine them into one.

We could keep all of them for the current major version, including the prefer-to-be. And mark prefer-to-be-xxx as deprecated. Then remove prefer-to-be-xxx with next major.

[G-Rath]

@SimenB cheers, good catch on that silly "too" 😅

[G-Rath]

@LitoMore as @razh said, prefer-to-be-undefined & prefer-to-be-null already cover undefined & null, but yeah I had totally forgotten about toBeNaN.

I think doing it all via one prefer-to-be rule makes sense, though I don't think we need the options for now. That'd actually let us support beDefined which is something we'd been stuck on because of the name

@SimenB do you have any opinions on that? mainly around having it in our style config, since prefer-to-be-undefined & prefer-to-be-null are there and so would want to be replaced.

[G-Rath]

also, I just realised this errors on toBe itself 🤦

[G-Rath]

I've created prefer-to-be in #864 which superseeds this :)

[github-actions]

🎉 This issue has been resolved in version 24.5.0 🎉

The release is available on:

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

Your semantic-release bot 📦🚀

[github-actions]

🎉 This issue has been resolved in version 25.0.0-next.5 🎉

The release is available on:

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

Your semantic-release bot 📦🚀