Make zxcvbn infallible #78
Conversation
Could you re-approve the workflow? Also can you make a release after? I guess this will be a breaking change. |
|
+ I think you should take a look at #77. It's better to write the score as an enumeration because it allows the compiler to pick the fastest representation for score (micro-optimization). It's a little incorrect because it should have |
|
I have mixed feelings on #77... From a performance standpoint, it's a micro-optimization that will be negligible compared to the other computations the library has to do, so I'm looking at it from a user experience standpoint. I'm probably just stuck in my old ways thinking that numbers are nice... Realistically, having an exhaustive enum is probably better. I can take another look at that one so the breaking changes can go out together. |
|
It looks like that MR should be fixable with a simple merge commit, which I've pushed up. I'll review it shortly. |
There shouldn't be any reason for zxcvbn to error. An empty password should still be treated as valid input and we can use instant/performance.now to calculate durations accurately without overflow.