vitest/prefer-to-be recommends to use toBe with floating points

[veritem]

vitest/prefer-to-be recommends to use toBe with floating points

[veritem]

I will push update for this shortly, thank you so much for reporting this

[veritem]

uuhmm, intresting, I haven't personally dealt with floating points, so do you have a repro I can base on fixing this rule?

[anisometropie]

here are a few simple examples you can use :

expect({ a: 1, b: 2, ...{ c: 3} }).toEqual({ a: 1, b: 2, c: 3});
expect('abcd' + 'efgh').toEqual('abcdefgh');
expect(1 + 2).toEqual(3);
expect(0.1 + 0.2).toEqual(0.3);

with the rule enabled, as you can see the first line is okay, toEqual is the right function to compare objects.
on the second line the rule wants me to change toEqual and use toBe instead, which is fine
on the third line, for integer the rule wants me to use toBe also, this is fine to too.

—> but on the fourth line, the rule wants me to use toBe for floating point, which is incorrect.

[veritem]

Hope the latest release fixes this issue

[anisometropie]

Thank you for your responsiveness in solving our issue :)

Now, having come to think a bit more about this, perhaps you could have another rule that follows the doc recommendation.

Both jest doc and vitest doc recommend not to use toBe with floating point numbers and to use toBeCloseTo instead.

Do you think having a rule for that would be helpful ?

PS: Pushing these reflections further .

we know that

• For scalar values like numbers and strings it’s better to use toBe
• it’s not recommended to use toBe for floating point numbers

I imagine having a rule that recommends using toBeCloseTo for floating point instead of toEqual could help.

The same problem arises for toEqual and toBe. These 2 tests fail because of the nature of floating points :

expect(0.1 + 0.2).toEqual(0.3);
expect(0.1 + 0.2).toBe(0.3);

But the only thing is that the doc doesn’t say anything about not using toEqual for floating points, So I’m really more sceptical about this part.

[veritem]

I get, i'll have to think abit more on additing a different rule. But does it still yell at you even on floating points?

[anisometropie]

No, the initial problem was solved, thanks for being so reactive.

[veritem]

awesome, I'll still consider your new rule proposal. I'm glad my quick fix was helpful.