`.not` is an antipattern

[btd]

.not modifier, while it looks very usefull from breaf view is clearly antipattern. I personally avoiding use it.
It produce additional class of possible problems like:

(10).should.not.be.a.Number()

There we see assertion object 10 to not be a Number, but assume you have more complex object you get from API response. So each time .not used need clearly rereview its usage.

Single usefull case for .not it is usage with .eql and .equal based assertions. When we know the actual object should not be equal to given in some way.

So probably it is worth to deprecate .not for everything by not .eql and .equal

[Qix-]

I'd be more interested in use-cases that claim to require the use of .not. Now that you mention it, I personally can't think of any uses of .not that wouldn't benefit from more specific assertions.

[tonylukasavage]

ditto above, been using should.js for years and have almost never used .not

[ncthbrt]

Testing removal is an example of where .not is very useful:
a.remove('b')
a now shouldn't contain b