Chai: .deep.members always throws a TypeError

Created on 27 Nov 2017  路  7Comments  路  Source: chaijs/chai

hello,

i upgraded chai in a project from 3.5.0 to 4.1.2 and got a lot of errors from comparing arrays of objects with .deep.equal. i checked the changelog and saw that checking equality has been changed a lot so i tried to rewrite those test with .members. i tried

expect([{
  type: 'whatever',
  payload: {
    message: 'blablabla'
  }
}).to.have.deep.members([{
  type: 'whatever',
  payload: {
    message: 'blablabla'
  }
}])

but got a TypeError: Right-hand side of 'instanceof' is not an object. i tried every combination of .members, .deep, .ordered and maybe .include with no luck. at the end i copied the example

expect([{a: 1}]).to.have.deep.members([{a: 1}]);

from the documentation but got the same TypeError. what am i missing?

bug

Most helpful comment

@gex I think something else is going on. Your last example works fine for me; I copied and pasted it into a new project with nothing but Chai 4.1.2 and Mocha. The first example is missing a ] to close the first array, but once that's fixed, it works fine for me too. May be worth deleting node_modules and reinstalling dependencies. I also wonder if there could be a package-lock.json issue. Since your stand-alone examples work, it's hard to speculate what the problem is that's causing errors in your project.

All 7 comments

@gex I think something else is going on. Your last example works fine for me; I copied and pasted it into a new project with nothing but Chai 4.1.2 and Mocha. The first example is missing a ] to close the first array, but once that's fixed, it works fine for me too. May be worth deleting node_modules and reinstalling dependencies. I also wonder if there could be a package-lock.json issue. Since your stand-alone examples work, it's hard to speculate what the problem is that's causing errors in your project.

@meeber I'm also get the same error only for to.eql and also in 4.1.2 version. I have tried to remove package-lock.json and reinstall packages again, but it isn't helps me. In 4.0.2 version
the errors isn't appear.
Error:

TypeError: Right-hand side of 'instanceof' is not an object
      at typeDetect (node_modules/type-detect/type-detect.js:179:13)
      at extensiveDeepEqual (node_modules/deep-eql/index.js:183:22)
      at Object.deepEqual [as eql] (node_modules/deep-eql/index.js:106:10)
      at Proxy.assertEql (node_modules/chai/lib/chai/core/assertions.js:1081:11)
      at Proxy.methodWrapper (node_modules/chai/lib/chai/utils/addMethod.js:57:25)
      at Context.it (src/redux/modules/status.test.js:94:14)

Code:

const state = {
  active: false,
  mode: null,
  ready: false
};

expect(reducer(state, {
    type: SET_SOURCE,
    source: '123'
})).to.eql({
    ...state,
    source: '123'
});

Thanks @MrEfrem. Based on the stack trace, I'm starting to suspect that a recent change to type-detect may be causing the issue. The error is happening on this line. That line is only hit in the first place if type-detect believes it's running in a browser environment. However, if globalObject.HTMLElement isn't an object, then that suggests either the browser detection or the global object detection is flawed.

Can you provide some details about what environment the tests are being run in? In particular, is it a node environment but with browser-like globals?

@meeber yes, it's node environment. Here my config:

require.extensions['.css'] = () => ({});
require.extensions['.scss'] = () => ({});

const jsdom = require('jsdom');
const { JSDOM } = jsdom;

global.window = new JSDOM().window;
global.document = global.window.document;

global.navigator = {
  userAgent: 'node.js'
};
global.localStorage = { setItem() {} };
global.window.localStorage = global.localStorage;

If I have made so, then it's work without errors:

global.HTMLElement = window.HTMLElement;

But maybe better to check HTMLElement and in window and in global object?
Because I don't think that other people will do so how I have offered above, because for emulating of DOM environment it isn't need by default.

@MrEfrem i鈥檓 also using an emulated browser environment because of enzyme. i will check your solution in the morning!

Hilariously this is the issue we tried to _solve_ with the patch to type-detect. Back to the drawing board I guess.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

huaguzheng picture huaguzheng  路  3Comments

domenic picture domenic  路  4Comments

ghost picture ghost  路  4Comments

meeber picture meeber  路  4Comments

sverrirs picture sverrirs  路  3Comments