Don't print array enumerable properties via inspect by default

The Problem

When using a library that modifies the array prototype, the expected [ ] to deeply equal [ ] becomes very noisy.

Here is a screenshot of this issue while using Ember:

Notice how small the vertical scroll thumb is.

I also created a minimum viable example as a gist.

The History

I then began to dig into why this ever came to be this way because it doesn’t seem useful to me. This led me to #120, #125, and https://github.com/chaijs/chai/commit/f76eedd46f282e0c948f0c9ad76221e9ae7d53b6

The tl;dr of those issues is inspect was originally borrowed from node, which does not print enumerable properties on arrays. This feature was added partly in support of .eql support for DOM nodes and matching that support when printing. This is reasonable since something like AssertionError: expected [ ] to deeply equal [ ] would lead to confusion.

The Proposal

I suggest that printing enumerable properties is an optional behavior just like show hidden is.

This way the more common case of plain arrays with modified prototypes get printed properly, and in cases where the enumerable properties are relevant, inspect can be invoked with the showEnumerable flag.

I think the only point of contention here is whether or not it’s safe to assume that whenever enumerable properties should be printed, an addon is preferred over a primitive assertion like .eql.

[keithamus]

There’s a sort of unwritten plan to refactor our inspection lib - loupe - and make it much more intelligent. It’s on my todo list after refactoring deep-eql (which will likely, hopefully, be this week). After the refactor this kind of issue will likely no longer be present - as our error messages will (hopefully) prioritise showing the different values of the two objects.

[lucasfcosta]

@meeber nice catch. IMO we could hide that kind of property for the members assertion, since it’s not taken into account we would have no problems showing a reduced part of the current output.

I was thinking about a flag which is config value, not an assertion chain, I’m sorry, I should’ve expressed myself better. Maybe comparePrototypeProps would be a clear name for it, but feel free to suggest other options, anyway, I feel like this won’t be needed at all after reading @keithamus’ post.

Since he has a nice solution for this I think we should wait for that refactor before moving on to more changes on top of this behavior.