-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update for Chai v4 #22
Conversation
Thank you for taking the time to go through this, @meeber! I'll track this with the chai v4 release. |
DO NOT MERGE. Chai v4 isn't released yet, version numbers in package.json still need updating. The second canary release of Chai v4 caused an additional test to fail. The test failed because of a bad interaction between In the failing test, |
|
I just took a look at this. I believe chaijs/chai-as-promised#157 needs to get merged (and a new version of |
Version 7.0 of domenic/chai-as-promised with support for chai@4 has been released. |
Update for chai 4 has been pushed in version 2.0.0. Thank you for the help and prodding! |
DO NOT MERGE. Chai v4 isn't released yet, version numbers in package.json still need updating.
I'm just going through some popular Chai plugins to see how much breakage there is when used with the upcoming Chai v4 release. It doesn't look like it breaks any of dirty-chai's functionality, but it does cause two tests to fail. I don't think these failed tests will impact end users of dirty-chai; they are specific to how assertions were being performed on actual Chai Assertion objects.
The test on line 127 fails for two reasons:
property
assertion is actually triggering the getter forchai.Assertion.prototype['neverFail']
, which is causing a__flag
property to be created directly onchai.Assertion.prototype
when setting thedefer
flag, which is in turn wreaking havoc on all future assertions. (This was happening in v3.5 too, just not with the same consequences).Assertion
object with the flags transferred over. Therefore, the secondshould
switches the context to the newAssertion
object instead of theneverFail
function, causing the assertion to fail.The test on line 129 fails because the
new chai.Assertion({})
that gets passed to theneverFail
getter viacall
is actually a proxifiedAssertion
object, which then gets double-wrapped inside another proxy inside of theaddChainableMethod
function. Therefore, whenshould
is called, it gets called twice (the second time is from within the proxy getter of the first call), and the end result is that the context is theAssertion
object instead of theneverFail
function.This PR refactors the tests slightly so that they work in both chai v3.5 and chai v4.0