assert.deepEqual & post-ES5 Data Types e.g. Map, Set, Iterables, etc

[timoxley]

Currently assert.deepEquals is ignorant of any new native data types introduced in ES6.

For example, this should probably throw, yet it does not:

assert.deepEqual(new Set([1, 2]), new Set([1]))

A good method might be to deepEqual against .keys() and .values().
deepEqual should also probably work with generic Iterables too.

[timoxley]

I guess a major issue is that there are many interpretations of what "deep equals" even means and perhaps making something sensible for ES6 data types would be inconsistent with the existing algorithm.

[vkurchatkin]

assert treats objects as key-value pairs. I don't think we should change that. This is something that can be done in a million different ways so it's probably better to leave that to user land. Also using it in a test is usually a bad idea, since for maintaining backwards compatibility you should check that specific properties exist and no that nothing else doesn't exist.

One interesting idea that requires some sort of standardisation is symbol properties that provide custom identity and equality functions (like Java equals and hashCode), but it's up to TC39.

[timoxley]

@vkurchatkin

assert treats objects as key-value pairs

Not all objects though, native Object types that existed in ES5 are special cased:
https://github.com/nodejs/io.js/blob/2a7fd0ad328d5197a9a166650e9eaa51367e3152/lib/assert.js#L152-L165

Set and Map are no more or less special than Date or RegExp.

Also using it in a test is usually a bad idea

Note that the tests for Node itself uses deepEqual extensively.

[Fishrock123]

I agree that it probably should be updated to properly deeply evaluate into ES6+ data types.

[vkurchatkin]

Not all objects though, native Object types that existed in ES5 are special cased

That is true, my bad. But these are not container types.

Note that the tests for Node itself uses deepEqual extensively

They use it to compare maps and lists of maps mostly. Otherwise it's possible to get unexpected results

[timoxley]

Copying in @domenic's comment regarding this from #2315

I don't think we should do this (or anything else in #2309). Assert should remain used only for testing io.js itself, and not try to be a good general assertion library. If io.js tests need this ability enough times that we need to factor it out, we should, but until then, just adding it because it'd be nice isn't a good idea IMO.

[Trott]

The TSC decided this week to lock the assert API and there's a pull request that will likely land in the next several hours to update the documentation to that effect and to suggest that people use userland assertion libraries. Given that, I think it's appropriate to close this issue, but if anyone feels differently, by all means, re-open.

[josephg]

This is disappointing. I enjoy the simplicity of using the built-in assert library, and the semantics for what deep equal means are well defined for sets and maps (a.size === b.size && everything in a is in b). And I don't see how this change would break backwards compatibility - the behaviour of assert in the face of ES6 types was always undefined.

Time to go trawling through npm.

[Trott]

@josephg The info in this issue is out of date. Subsequent to this decision, the locking of the API was reversed. (In fact, no APIs are locked anymore.) Any common-sense improvements to behavior of existing assert methods (such as assert.deepEqual()) are likely to be accepted, IMO.

[josephg]

Great, yeah I just read inspect-js/node-deep-equal#28 . If nobody else has done it I'll put together a PR to fix this behaviour.