refactor: comparable function

[ariskemper]

No description provided.

[fabian-hiller]

Why do you think this is necessary? comparableArray and comparableObject are only used once and the previous comparable functions seams not to complicated to me.

[ariskemper]

I think it's a bit easier to understand for newcomers on the project and since it is used across the project. That's why those 2 functions are private and exist only in the module. I also didn't like use of any type and change it to be more generic and i used unknown instead any in Record type.

[fabian-hiller]

Maybe there is a way to avoid comparable altogether. At least that is what I would expect from a testing framework.

[ariskemper]

@fabian-hiller it could be solved with JSON.stringify and i removed comparable.

[fabian-hiller]

JSON.stringify() is a good idea. Let's keep that in mind when rewriting the tests. I will give you feedback on the email tests today.

[ariskemper]

@fabian-hiller i allready rewrote tests and remove comparison function in this PR :).

[fabian-hiller]

One thing to note is that if the properties are in a different order, the JSON.stringify() solution breaks. This was perhaps the reason I implemented comparable.

[ariskemper]

@fabian-hiller indeed good to note that, do you think is this a feature or issue? :)

[fabian-hiller]

The order should not matter. That's why we should probably stick with comparable if there is no other solution.

[ariskemper]

@fabian-hiller we could use extend matchers and add extra method toCompare? extending-matchers

[fabian-hiller]

Can you send some sample code showing how you would implement it?

[ariskemper]

@fabian-hiller i implemented changes with custom vitest matcher toEqualSchema in this PR. I was not sure regarding naming for toEqualSchema matcher or maybe toCompare?

[fabian-hiller]

Thank you! This looks great. I will review it once I made some more progress in other areas of the library.