Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

deepEqual should not compare constructors #1765

Open
runspired opened this issue Jun 17, 2024 · 2 comments
Open

deepEqual should not compare constructors #1765

runspired opened this issue Jun 17, 2024 · 2 comments

Comments

@runspired
Copy link

Currently, deepEqual will do a strict equality comparison on the constructor of each value. This defeats the purpose of deepEqual in that it prevents it from matching structurally, and leads to the myriad of issue reported in qunit over the years around comparisons of Array vs TypedArray and the like.

@runspired
Copy link
Author

related: #1706

@Krinkle
Copy link
Member

Krinkle commented Jun 18, 2024

@runspired Would you mind adding an example of two values you'd like to equate with QUnit that are currently treated as different by deepEqual?

Regarding comparison of the constructor property, note that it is an explicit part of deepEqual() to validate what class an object is an instance of. This catches issues where a method may return one of several classes. They might even store the same kind of state. It also avoids mistakes where two unrelated classes may store similarly-named fields. This also removes the need for boilerplate like assert.true(x instanceof Foo);.

There are broadly two answers to what class an object relates to. One way is by comparing the constructor property. That's what QUnit does and matches the behaviour of instanceof in JavaScript. Another way is to compare the [[Prototype]] pointer via Object.getPrototypeOf(). This is what Node's assert module does (source). This is more strict and would reject even a Proxy object that wraps an equal class instance. Back when we made this choice, Proxy object's weren't a thing, but it does add a threshold for changing how we do it.

Is there an alternative, less strict, way of comparing the constructor that you would prefer?

Would assert.propEqual() work for your use case?

If not, are there other checks in deepEqual that you'd like to keep that propEqual lacks?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants