ok() is not a function

Hello!

Thank you for this great library!

I’m using a construct like this: expect(value).to.not.be.ok(), however, I’m getting an error cause ok is not a function.

When I use it like this: expect(value).to.not.be.ok, it works fine, but raises an error in my IDE, cause this construct is not a call and is not assigned to anything, i.e. redundant construct.

I think it makes sense to make such constructs at least look like a normal function call like in my firxt example: expect(value).to.not.be.ok().

What do you think? Thanks!

[keithamus]

Just to clarify the matter: we still get lots of requests regarding this. I think eventually, when we tackle some of the things on the Roadmap - we’ll have the flexibility of offering interfaces which don’t use properties. But I think it’d be very turbulent to change things right now. For now, linters & IDEs can be tweaked, or you can use dirty-chai - as @meeber mentioned.

I’ll close this because of all of the above discussion, which is to say “we’re not saying wontfix, just wontfix-right-now”.

[meeber]

I think it’s worth looking into again. Just to make sure we don’t duplicate past efforts, here is a quote from @keithamus in the #371 thread that contains a ton of background information related to the original fix to this issue and the reason it got reverted:

• #41 was the initial proposal to add method syntax (.to.be.true()).
• #297 was the PR that was merged by me.
• #302 is where the original discovery that the two styles were incompatible with each other was.
• #306 is where we reverted the change.
• #321 and #326 are duplicates of this issue.