Mitigate array-of-statuses' impact on JSON bodies

[swantzter]

fixes a regression in #715 / v6.1.4 which introduces a breaking change where any array passed as the first argument to .expect() is treated as an array of status codes, rather than as a body which was the previous behaviour. This tries to minimise the impact of status code arrays.

Given, this will still break if the expected body is an array of numbers, but it will at least break less, and perhaps array bodies can be deprecated/removed in the next major release providing proper notice of the change?

[niftylettuce]

v6.1.5 released, can you further improve this by ensuring that besides being a number, they are one of the valid status codes as well in the 200-500 range?

[benjosantony]

[].every(val => typeof val === 'number')) still return true, so incases where we are expecting the body to be empty array, this wrongly identifies the intention to be for testing status codes.

Changing the condition to if (Array.isArray(a) && a.length > 0 && a.every(val => typeof val === 'number')) { should fix that. (Basically add a check to be falsy when array length is zero as .every is truthy for empty array https://en.wikipedia.org/wiki/Vacuous_truth)

[benjosantony]

I have raised a PR for that #735 @niftylettuce

[niftylettuce]

v6.1.6 released

[swantzter]

thanks, I'm not sure limiting to 200-599 is the correct route to me, sure it'd probably mitigate more cases, but http status codes can technically be any number from 0 to 999, for example that's how the fetch spec treat then, that way it feels like it could just lead to more confusion why [200, 204] works, but suddenly when you add your own vendored status code [200, 204, 609] it doesn't