feat(email) allow for custom mail implementations

[JipSterk]

☕️ Reasoning

currently solutions using a custom configuration of sendVerificationRequest for the nodemailer provider still require a server config object passed even though it's type is not mandatory which is not need for implementations that for example use a sdk like aws-ses or react-email

🧢 Checklist

• Documentation
• Tests
• Ready to be merged

🎫 Affected issues

📌 Resources

• Security guidelines
• Contributing guidelines
• Code of conduct
• Contributing to Open Source

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
auth-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 27, 2024 4:08pm

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
next-auth-docs	⬜️ Ignored (Inspect)	Visit Preview		Aug 27, 2024 4:08pm

[vercel]

@JipSterk is attempting to deploy a commit to the authjs Team on Vercel.

A member of the Team first needs to authorize it.

[JipSterk]

i couldn't figure out why this server object was needed outside of development purposes

[ndom91]

I think this PR is no longer necessary. We shipped multiple http request Email providers (which can be extended). Can you check out these links and let me know if that covers it for yuo?

• Custom Email Provider Guide: https://authjs.dev/guides/configuring-http-email
• Example new HTTP Email Provider (Resend) guide + customization examples: https://authjs.dev/getting-started/providers/resend

[JipSterk]

hi @ndmom thanks for the suggestion, i haven’t stumbled upon this page in the docs and it seems like this is exactly what i want! however when i define an object with the same properties the typescript compiler will complain that the following properties are missing: name, from, maxAge and options which is of the EmailUserConfig type with basically the same options. i assume these aren't required? if so i can update the pr which makes these properties optional to reflect the example on the docs. just to make sure but these are the versions i use:

"next-auth": "5.0.0-beta.18",
"@auth/core": "0.31.0",

[ndom91]

@JipSterk which object are you referring to that's giving you TS issues? Could you provide some code example or point to the relevant piece in the example pages I linked to above?

Also what are you using @auth/core for exactly? That shouldn't be necessary to install, only next-auth, for example 🤞

[JipSterk]

that would be EmailConfig it requires the properties mentioned above which are: name, from, maxAge and options. in the example shown on the page you mentioned these properties are not defined so is the example wrong or could these types become optional?

[ndom91]

@JipSterk thanks for pointing this out, it looks like both could use a bit of updating.

1. The example should include most of those fields.

   • maxAge is important for defining how long the verificationTokens should be valid. Although we could safely default to something like 24hrs in the @auth/core code..
   • name is just the name of the provider that by default gets put into the btn on the login page, like "Login with X"
   • options we don't really need in this situation actually and can be made optional
   • from is also potentially optional depending on how you implement the sendVerificationRequest function yourself. If you hardcode a from address, like in the example in the guide link from above, then you don't need to pass it in at the provider level here.

2. So regarding the types..

   • from can be made optional
   • optoins can be made optional

I've updated the guide to show the use of maxAge and name. Could you cover the type updates?

I dont thinkt he changes to the nodmeailer provider in this PR are necessary anymore, right? What do you think?

EDIT: Just noticed that maxAge does fall back to 24hrs already (packages/core/src/lib/actions/signin/send-token.ts:57), so that can be made optional as well in TS