Issue using chai-enzyme alongside chai-jquery

[rylanc]

The root of the problem appears to stem from the fact that chai-jquery uses checked as a property:

expect($(node)).to.be.checked;

While chai-enzyme implements it as an assertion method:

expect(wrapper).to.be.checked();

If I call chai.use with chai-jquery first, chai-enzyme chokes while trying to add the checked assertion (chaiWrapper.addAssertion(checked, 'checked')): Uncaught TypeError: Cannot read property 'is' of undefined

If I call chai.use with chai-enzyme first, chai-jquery overwrites the checked assertion as a property.

Any ideas on how to make them play nice together?

[ljharb]

noop matchers are a huge antipattern. Could we convince chai-jquery to make a breaking change to make that be a function matcher?

They don't even have to make it breaking - they could make the getter do the assertion, and return a noop function that could be invoked.

[vesln]

i have push access to chai-jquery and can do the change and release another major version...

...however, it seems pointless to tackle those specific cases, since we are planning to rework the entire chai.js plugin system... timing is unclear but @keithamus might have an idea

until then I will suggest to implement a workaround... an assertion that overwrites both jquery's and enzyme's checked and invokes the necessary code depending on the input

otherwise it simply feels like treating the symptoms and not the underlying cause

[keithamus]

since we are planning to rework the entire chai.js plugin system... timing is unclear but @keithamus might have an idea

Timeline for this is many months away. Maybe we will have it by end of this year.

until then I will suggest to implement a workaround... an assertion that overwrites both jquery's and enzyme's checked and invokes the necessary code depending on the input

As unpleasant as this might be, it sounds like the easiest workaround IMO.

They don't even have to make it breaking - they could make the getter do the assertion, and return a noop function that could be invoked.

We tried doing this in chai core. Suffice it to say that it did not end well and we reverted it pretty quickly.

otherwise it simply feels like treating the symptoms and not the underlying cause

This issue highlights a failing in the current chai plugin system. We should absolutely (and are planning to) fix this, but it will take a long time. I don't have an answer for the best workaround for now - sorry 😞

[ljharb]

when you rework it, can you prevent noop function matchers? It's a hugely bad pattern to use, and it makes mocha unusable in ES3 environments (browsers many of us still have to support).

[keithamus]

@ljharb I don't want to hijack this thread, so I'll just say we have an issue (https://github.com/chaijs/chai/issues/585) which details what the new plugin interface will look like. Plugins will be abstracted away from decisions like property based assertions, and it will be determined by interface.

[eugenet8k]

Hi guys, it's been a while and I guess the chai plugin system wasn't updated yet. But, can anyone post some feasible solution or workaround or hack to solve this issue meanwhile?

In my case, some of my modules have unit tests for jQuery based UI and another for React based, so if I only get an idea how to initialize chai per module then I would use chai-jquery and chai-enzyme independently. Although it seems if I call chai.use once the plugin stays there forever until I restart the browser. I couldn't figure out a way to initialize chai within a module scope. Is there a way to do so?