-
-
Notifications
You must be signed in to change notification settings - Fork 697
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
Deep equal with symbols as keys does not fail #1054
Comments
@fflorent Thanks for the issue. I believe that these lines are responsible for this behavior; It's worth noting that the deep equality algorithm in the Node.js Thoughts @keithamus @shvaikalesh @lucasfcosta @vieiralucas? |
Yes I think we should compare symbols too. However this will be a breaking change. This is also tangentially related to chaijs/deep-eql#38. We could implement it right now in deep-eql then perhaps hide it behind an optio like |
I agree that we should compare symbols. @keithamus, can we do something like start a v5 branch and launch Please let me know if this does not make any sense at all 😸 |
@vieiralucas I'm not the BDFL - we are equals here, if you want to start a v5 branch you are welcome! I would warn though; we did this with v4 and it was quite a pain to merge to master, as we weren't immediately porting bug fixes over to v4 from master, so if we are to do this, then I would recommend v5 needs more attention than just a dumping ground for breaking changes. What are your thoughts around having it behind an option in deep-eql though? |
My initial thought: we should compare symbols by default; if someone would like to store metadata on objects (like observers), they should resort to However, we lack real-world use cases of symbols to be confident that opt-in will be better in terms of DX than opt-out. Also, if we are comparing symbols, we should be careful when detecting polyfilled ones. |
@shvaikalesh Hi. I have one real-world use case for symbols. Sequelize module recently implemented their operators using Symbols, since it's more secure ( http://docs.sequelizejs.com/manual/tutorial/querying.html#operators ). Now, it's much more tedious to write unit tests, in order to test these operators. It's still possible, but quite challenging. Check this. this is how it could look if chai would assert Symbols correctly:
( All the values inside But, now, in order to test this, i have to do some totally crazy stuff. |
yeah I just faced this issue with sequelize. You just have to write proeprty tests by hand and it seems to work. //test symbols independently
expect(out).to.have.property(symbol1).that.equals('hello');
expect(out).to.have.property(symbol2).that.deep.equals(['merge', 'symbols']);
expect(out).to.have.property(symbol3).that.equals('world');
expect(out).to.have.property(symbol4).that.deep.equals({
hello: 'hello',
overlap: 'new',
goodbye: 'goodbye',
}); |
Right now |
@keithamus wil look into that, thanks |
Definitely useful for testing out queries with sequelize. +1 |
Any update on this? It'd be really awesome to test symbols. +1 |
Hey @fflorent thanks for this issue. Thanks to everyone else for commenting on this and showing your support. We've added this to our Roadmap https://github.com/chaijs/chai/projects/2! We'll be releasing chai 5 soon, but for now I'll close this issue because it is tracked on our roadmap. |
There is a simple workaround: Node.js Example: const { inspect } = require('util');
const { expect } = require('chai');
const foo = { [Symbol('a')]: ['1'] }; // also works with Sequelize operator, eg [Op.in]
const bar = { [Symbol('a')]: ['1'] };
const fooSerialized = inspect(foo, { depth: null });
const barSerialized = inspect(bar, { depth: null });
expect(fooSerialized).to.deep.equal(barSerialized); |
@janlukasschroeder thank you, your advice helped me a lot! |
For those who do not want to compare objects using inspect, you can instead use lodash method isEqual.
|
it doesn't work |
@Rest11 have you used a Sequelize symbol? |
Hi all! I put up a PR that seems to fix the |
Hi,
The following test should fail but doesn't:
Thanks!
Florent
The text was updated successfully, but these errors were encountered: