Skip to content
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

Consistency with returning new Assertion instead of this #791

Closed
meeber opened this issue Sep 9, 2016 · 6 comments
Closed

Consistency with returning new Assertion instead of this #791

meeber opened this issue Sep 9, 2016 · 6 comments

Comments

@meeber
Copy link
Contributor

meeber commented Sep 9, 2016

A change was made a few months ago to return a new Assertion object with flags copied over instead of returning this. References: #562 #642

However, it looks like there are still some spots where this is returned. The only one I've actually tested so far is overwriteProperty.

For example:

const {expect, use} = require("chai");                                                                                  

use(function (chai, utils) {                                                                                            
  utils.overwriteProperty(chai.Assertion.prototype, "and", function (_super) {                                          
    return function blah () {                                                                                           
      _super.call(this);                                                                                                
    };                                                                                                                  
  });                                                                                                                   
});                                                                                                                     

it("but", () => {                                                                                                      
  expect([1, 2, 3]).to.be.an.but.length.below(1000)    // Passes
});

it("and", () => {                                                                                                      
  expect([1, 2, 3]).to.be.an.and.length.below(1000)    // Fails
});

As expected, the second assertion fails with error: "TypeError: expect(...).to.be.an.and.length.below is not a function" because the overwritten and is returning the function that was originally returned by the chainable method an instead of returning a new Assertion.

Other places where this might be a problem (but I haven't tested):

@lucasfcosta
Copy link
Member

Well noticed @meeber, thanks for the awesome job! 😄
This really seems to be a problem, I feel like we need to solve it before releasing 4.0.0 just to keep the API consistent.
I think this will be a pretty easy thing to fix but it will require some time to check if any other places need a fix too.
Right now I'm finishing the 4.x.x migration guide and I'm going to review the merge you have done, but after doing that I may be able to fix it. If any contributor wants to give it a shot please feel free to do so, I will make sure to post another comment here if I start doing anything related to this.

@meeber
Copy link
Contributor Author

meeber commented Sep 10, 2016

Interestingly, I just discovered that this issue is blocking us from adding proxy support to overwritten properties. When a overwritten property returns this, it's the non-proxified version. Would need to either wrap this in a proxy or return a new Assertion like the addProperty function does.

@meeber
Copy link
Contributor Author

meeber commented Sep 10, 2016

Also, I've always wondered about this part of the logic: In what situation is result not undefined?

@meeber
Copy link
Contributor Author

meeber commented Sep 13, 2016

Hey @vieiralucas welcome aboard!

NOW FIX THIS!

@vieiralucas
Copy link
Member

vieiralucas commented Sep 13, 2016

YES SIR! 😸

I'm still reading through all the issues and PR's involved in this issue.
I think I'll be able to submit a PR addressing thi later today.

@lucasfcosta
Copy link
Member

@vieiralucas This PR #642 has more details about it. I think this post explains the reason behind this whole thing, I highly recommend anyone involved with this issue to read that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants