Closed OneHoopyFrood closed 9 months ago
Hey, thanks for the issue.
I don't think this would make much sense, as all matchers are required to be executed anyway in any order because the scoring results from all different matchers at the end. One matcher doesn't know the outcome of the other matcher, vice versa.
The pwned custom matcher is a special case as it is currently setting the scoring to 0 by default. Which means the other matcher are not needed if a pwned match was found. But this is too much hassle to implement for a custom matcher. Aside from that i would like to change the scoring of the pwned matcher in the future in some some way 🤔
But as you already described in #194 your specific use case will be resolved in a simpler way with the new usage of this library.
Since this seems to be resolved here, i will close the issue
It would be helpful to be able to specify the order in which matchers can be executed.
My specific desire is to delay the use of the pwnd matcher until the password has already passed all other sync checks. This would save on needless networked calls.
It could be done via a 2d array, perhaps?
matcherOrder: [['minLength', 'repeat'], ['pwnd']
That would indicate the
minLength
andrepeat
matchers are fine to execute concurrently, but only after they both pass shouldpwnd
matcher execute.This is just a spitball idea of how such a configuration could be approached and there are obvious difficulties with it as it would be challenging to type safely. (All strings must be keyof Matchers, and all Matcher properties MUST be represented.)
This is the kind of puzzle I would enjoy working out, but I don't want to waste time with a PR if the community doesn't want this.