Some unit tests don't make sense

[j-refs]

Trawling thru the unit tests, I've noticed some failed tests that I really think should pass.
For example:
not ok 223 empty buffer and empty array are not equal
I, would honestly expect and empty buffer and empty array to NOT be equal. One holds arbitrary data and one holds bytes. So why then, are them not being equal a fail?
Also:
not ok 303 Date and RegExp are not equal
I cannot see any scenario where a Date and a RegExp would be any type of equal, them being 2 completely different types with completely different intended functionality. So then why is them not being equal a failed test?

I want to adopt this library, but I need to ensure I won't have any... Surprises.

Can someone explain these test results and maybe convince me to integrate this library?

[ljharb]

I'm confused, all the tests are passing on main.

As for buffers and arrays, they are considered not equal, whether strict or loose, regardless of contents.

Similarly, Dates and RegExps are not equal, whether strict or loose.

In what node/npm version, or browser, are you running into these failing tests?

[j-refs]

I was simply referencing your CI tests

[j-refs]

The one I was referring to, regarding your program determining that a date and RegExp are equal, based on your test:
https://github.com/inspect-js/node-deep-equal/actions/runs/7715085317/job/21028804846#step:4:537

[j-refs]

Just saying, some of those test results are very concerning from a long term stability viewpoint. I'd love to use this library, but I wouldn't feel good about code considering a date and a RegExp the same being in stability focused code. So I'd like to know what that's all about so I can possibly reconsider, because this looks more promising than anything else

[ljharb]

Those are the native node tests, that don’t invoke this package’s implementation. It’s in node < 12 that that’s the case.