The README suggests that instead of this, you should check entropy. That's a little tricky! Entropy in the traditional information-theoretic sense is a property of a random variable. You need to know what distribution a user drew it from. You can make educated guesses (e.g. if long, probably using password manager, if using password manager, probably fixed length) but that usually only tells you something useful about the _good_ passwords, and not the bad. You don't care about the good passwords. If the user entered "correct horse battery staple" but the user _always_ uses that password, a sufficiently informed attacker experiences 0 bits of entropy.
So, entropy estimation is pretty bad, and we end up with imperfect password rules. Here are some ideas:
1. Make an educated guess about the distribution. Is it "correct horse battery staple"-like? Because then maybe don't tell people to add special characters if it's long enough. Relaxing requirements when people add numbers is tricky; turns out people are really likely to add those numbers at the end, and then it's probably a bad reused password like sparky1 or whatever.
2. Filter extremely common passwords, and things directly linked to usernames.
3. 8 <= len <= 70 or so (otherwise you'll get probably-bogus Hackeroni submissions about DoS).
4. No scheme will save your user from shitty passwords. bcrypt, scrypt, argon2, whatever -- not an excuse for not protecting your password database.
5. If you wanna be really fancy, use your guesstimate about the source distribution to produce an entropy estimation. Entropy is the nerd-proof answer, but most consumers don't know what it is. Whether or not telling users something like "try making your password longer" or adding a new class of special characters is friendly UX and whether that actually makes them use significantly better passwords versus the moral equivalent of sparky1 is an open question; I don't think it's an unreasonable assumption that both work out worse than you might hope.
It's important to note that this doesn't need to be perfect (and strictly speaking, it can't be). You just need to stop non-advanced users from shooting themselves in the foot, and ideally prevent power users from being annoyed at your service.
I should really turn this into a library :-) But before you do any of this fancy stuff? Implement 2FA, ideally U2F. No work you do on password rules is going to compare to what you get if you allow shitty passwords, but most of your users use U2F. Just get started now. I know U2F has limited distribution right now. That's a chicken or the egg problem. You can do TOTP too, but trust me, U2F is way, way better.