Include non-enumerable properties #482
Conversation
Move checking object equality into a separate common function utils.checkObjectEqualityUsingType(). Use this within the base object type but also when comparing Error keys - since this function accepts the type, in the case of the Error type it ensures equality is evaluated using the subtype getKeys() thus addressing the mismatching keys issue.
Account for the addition of an "isOperational" property that is added for any error that passes through the bluebird promise implementation.
papandreou
left a comment
papandreou
left a comment
There was a problem hiding this comment.
I'm on board with this. Looks great and the approach seems solid!
| const valueKey = valueType.valueForKey(value, key); | ||
| const valueKeyType = expect.findTypeOf(valueKey); | ||
| const isDefinedSubjectKey = typeof subjectKey !== 'undefined'; | ||
| const isDefinedValueKey = typeof valueKey !== 'undefined'; |
There was a problem hiding this comment.
Shouldn't Key be replaced by Value in the above 5 variable names?
|
@alexjeffburke the Node 0.10 build has failed, is that something that is fixable? |
| const keys = valueType.getKeys(value); | ||
|
|
||
| const subjectKeys = subjectType.getKeys(subject); | ||
| const valueKeys = valueType.getKeys(value); |
There was a problem hiding this comment.
Mhh I know this is my mistake, but I think things will be much more clear if we called subject actual and value expected in this method. We can always fix that later.
There was a problem hiding this comment.
or maybe subject and spec.
|
I tried to improve performance by using indexes and what not, without luck 👍 It is as fast as master. Node v0.10.48 does not fail locally - don't know what is going on with that. It is only the failing tests that worries me right now, otherwise I would say 🚢 |
|
I can reproduce the failing tests, by merging to master locally and running make travis on Node v0.10.48. |
|
If I blacklist |
|
Okay here is the plan. When on Node 0.10 blacklist Then this should be good to merge. Thanks for the hard work and sorry for the late review. |
|
Thanks both for looking at this - I’ll try to find time to execute on the comments over the next few days. Look forward to getting this in too :) |
|
👍 I think the change will only take you about 5 minutes as we already found the solution, so do worry that fixing this is a big task. It is really great to see very deep improvements like this, well done 👌 |
|
@alexjeffburke: Fixed the node.js 0.10 issues here: https://github.com/alexjeffburke/unexpected/pull/1 |
|
@papandreou I've folded your fixes into this branch - thank you and @sunesimonsen for tackling these last bits. With the tests all passing, how do you both feel if finally go ahead and merge? :D |
|
I guess that depends on whether we want to get it into a major release with those other things? Either way, I think it'd be fine to merge it and then create a legacy |
|
@papandreou too late, but I'm not overly happy about master becoming a development branch for v11. What is breaking about this PR? |
|
It must be some subtle breakage. |
|
@sunesimonsen ah crap, sorry - it’s only if folks were relying on non-enumerates properties being ignored. In practice I really doubt this affects anyone, and if it does then there’s a chance it’s helpful to highlight this to them. I’ve been 50-50 about just releasing this as another minor, which would also be equally fair - I’d love to see this in people’s hands of course :) |
|
@sunesimonsen, the fact that object |
|
I think the major makes sense just out of principal. But I don't like changing our release and branching strategy for it. I guess we just need to get v11 in shape then 😊 |
|
Hahaha ok then I’ll take my part of the consequences of having lit a fire under v11 :p ..will give the branches you mentioned before another review @papandreou. cc @sunesimonsen |
|
I think we should just aim for a small enhancement version and push larger features to v12. |
…cludeNonEnumerableProperties"" This reverts commit aeac1ef.
|
Moved to #509. |
Revert "Merge pull request #482 from alexjeffburke/feature/includeNonEnumerableProperties"
…cludeNonEnumerableProperties"" This reverts commit aeac1ef.
3 participants
This branch adds support for including all properties regardless of enumerability for object comparisons. This is definitely further than a prototype but I imagine will want a thorough review both on the code itself but also 'philosophically'. Note some interesting cleanups/simplifications in a few places were possible around key handling.