Currently, this build fails due to keys in the object being validated being in a different order than they were previously. I didn't update this test because I want to look into the root cause to see why my changes caused this to occur.

Don't trust the diff, it only compares both stringifications, which can happen in different orders, but there's still something different somewhere.

@Marsup So I figured out what caused it to change the order, still trying to understand why. The extra variable encoding which I was passing causes the variables within the context to be added in a different order. Removing encoding from the context for the error makes the test pass, and moving the limit and value variables around causes the tests to fail once more since the context is constructed differently yet again.

I think the passing the encoding to the error so that it can be used in custom error messages is useful. I could update the part in the compare property where errors are created to only add encoding if it is truthy, but that's not how the rest of the library creates errors.

I added encoding back and updated the tests to have the keys in the new order for when encoding is included. This makes the objects the same but Hoek is still reporting them as not being equal...it really seems like no matter the order of the keys Hoek should consider them to be deeply equal, but that's a different problem.

Previous tests failed because encoding was being included in the context as undefined but wasn't included in the expected values. The assertions don't show the difference because the assertion only asserts that the value should be undefined and therefore doesn't display it.

Like I told you, the order doesn't matter, if you have an error there is something different.

Seems OK, can you squash all those commits ?

@Marsup Should be squashed now, first time doing it but I think I got it. I guess GitHub still shows the older commits that occurred, but my repo only shows them as the new squashed commit.

Nope, github should show only one commit, it seems you did a merge with yourself, I don't know what happened here :)

Yeah, I think it was my lack of knowledge squashing stuff. When I pushed Webstorm had me choose Merge/Rebase after I squashed everything. I chose merge, and it merged to itself and undid what I squashed.

I've been trying to undo the merge or squash all of the things together again, but I just can't seem to figure it out.

I'll merge it manually then. Anyway I want to change the target since merging to master would keep me from releasing further 6.0.x versions.

Merged in branch 6.1.0.

Cool, thanks @Marsup !

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.