feat: @effect/vitest custom testers

[sukovanej]

The MVP of #2629

[changeset-bot]

🦋 Changeset detected

Latest commit: 903c9e2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@effect/vitest	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[tim-smart]

I wonder if it would be better to add a tester that checks for Equal.isEqual and uses Equal.equals if true.

[sukovanej]

I wonder if it would be better to add a tester that checks for Equal.isEqual and uses Equal.equals if true.

I'm exploring this option, the problem is the fallback on strict equality for objects not implementing Equal, e.g. chunk or list containing arbitrary objects.

[mikearnaldi]

Wondering if we can make equal act structurally for plain objects with a regional flag

[mikearnaldi]

testing the idea here: #2662

[sukovanej]

While making the equals a little bit smarter by moving closer to the comparison by value absolutely feels like a good move, IMO we should still not break the equality logic of the vitest. Vitest (and I assume generally any testing lib) can have its own comparison logic and most importantly a mechanism for injecting a custom testers (users of Vitest can introduce their own equality for specific cases), therefore the best way to approach this seems to be to introduce an equality tester checking effect's data types "structurally" and than giving the control back to the equality logic of the testing lib for other nested values.