Add toBeEnabled matcher

[lourenci]

What:

Add toBeEnabled matcher to the library. This PR closes #76.

Why:

It feels more natural to write the specs. Most of us don't like to double negation tests.

How:

I just "negated" the toBeDisabled matcher, including the spec file. To aim that, I extracted the logic to the utils file.

I don't know if that is the better approach to aim that, I don't even know if the utils.js is the better file to contain some "shared" logic to be shared between matcher files. So, it would be good that someone take some time to review that.

Checklist:

• Documentation
• Tests
• Updated Type Definitions
• Ready to be merged
• Added myself to contributors table

[gnapse]

I think I'd prefer if you keep all the to-be-disabled.js file as it was, and added the new toBeEnabled to it, then export both from the same file. I know it kinda breaks this pattern where each matcher has its own source file, but in this case these two are close enough that I think it's warranted. As for the tests, you can also keep a single test, and add new assertions for toBeEnabled that are negations of the equivalent assertion for toBeDisabled.

(Feel free to try to sway me the other way if you feel strongly against this suggestion).

[lourenci]

I don't have any arguments to keep what I've done. The toBeEnabled matcher is just a negated form to toBeDisabled. I'll do that. :)

[lourenci]

@gnapse it's done. :)

[gnapse]

🎉 This PR is included in version 3.1.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀