Add optional matchers support to the plugin.

[ixahmedxi]

Context

Hi, I would firstly like to start by saying thank you for this great plugin, not only that the functionality of it is awesome but it was also a great source for me to learn about better-auth plugins and how they are written.

I've been playing around with better-auth to create a sign in flow that is based upon magic links, when I added your plugin expecting it to work on the magic link sign in, I noticed after going through the source code that it matches against the /sign-in/email path, meaning it wouldn't match with magic link sign in which is /sign-in/magic-link.

I've resulted to copying the source code of the plugin, changing the matcher & also adding the mailchecker validation in before hook to support validating emails before sign in attempts with magic link since user creation is after an email is sent & I wanted to run mailchecker before an email is ever sent.

Proposed solution

I have been thinking if this could be integrated into the library, possibly through making matchers become an optional parameter, where you could override it to for example work with magic links.

Or maybe we could adapt the plugin to other email based solutions like magic links/otp...etc through parameters like magicLink: true on the plugin's function.

I'm open to any suggestion & open to contributing this myself.
Again, many thanks for the awesome work with this plugin <3

[GeKorm]

What a great idea! Thanks for taking the time to write such a nice proposal. It did feel odd to hardcode the path string.

How would you feel about a mix of both solutions; allow passing a matcher as a plugin option, but also export common matchers for ease of use? For example something like this:

import emailHarmony from 'better-auth-harmony/email';
import * as matchers from 'better-auth-harmony/email/matchers';

export const auth = betterAuth({
  plugins: [
    emailHarmony({
      matchers: [matchers.email, matchers.magicLink, matchers.emailOtp]
    })
  ]
});

[ixahmedxi]

@GeKorm I like that approach yeah that would be great!

I was also thinking about suggesting enabling some optional callbacks that would allow users to run their own custom validation/logic on top of the default? like for example onDatabaseUserCreation and onBeforeHookHandler which would be useful in case scenarios like for example putting in arcjet's email mx record checks ontop of the default validation.

However, I think that exporting the matchers also allows you to easily create an extra plugin and put that extra/custom validation in another plugin so I think it should be fine, what do you think?