Nest.js should have a mail module that provides an integration for nodemailer/email-templates.
There are already third-party solutions available, for example:
However, I suggest to provide an official solution like other major web frameworks (Laravel, Ruby on Rails or Spring Boot), as most business cases require mail services (e.g. password reset, notifications).
@Module({
imports: [
MailModule.forRootAsync({
useFactory: () => ({
transport: 'smtps://[email protected]:[email protected]',
defaults: {
from: 'Example <[email protected]>',
},
template: {
dir: __dirname + '/templates',
...
},
}),
}),
],
})
export class AppModule {}
So, if Nest were to create an "official" module, what package would be the underlying one? @nestjs/bull
uses bull under the hood. @nestjs/typeorm
uses typeorm. So what would @nestjs/mailer
use?
Personally, I don't see the need for Nest as an organization to create another wrapper module around a package when the community has already done so.
@nest-modules/mailer
is based on nodemailer
, but the template system was developed by the authors themselves. Unfortunately, EJS templates are broken at the moment and it supports neither multipart emails (HTML and text) nor multilingual templates.
email-templates
is used by lad
(another Node.js framework) and supports not only multipart emails and all common template engines but also i18n (based on @ladjs/i18n
).
So, the Nest.js module could just be a wrapper for a fully-fledged package like email-templates
or implement the template system itself (maybe with a nest-specific i18n module).
To me, templating emails and sending emails are two different domains, so they should theoretically be two different modules.
Scott
I don't think there is a need to have separate modules, as in most environments it's best practice to create template files for the different use cases (e.g. email confirmation, password reset, daily activity report).
Nevertheless, it should be possible to pass just a raw HTML string. This is how it's done in the libraries I referred to in my first comment.
Yes, but some people might want to do their email templating differently. So, what I am getting at is, the email module from Nest should be _only_ for email transfer. Then the community can come up with modules for templating them.
Scott
But why should Nest not provide a solution out-of-the-box? I don't think that the majority of Nest.js users need to implement their own email templating aside from EJS, Handlebars, Pug (and many more).
In my opinion, email-templates therefore meets all requirements for a solid mail package that @nestjs/mail
could rely on.
@jonasbeyer I was able to find this comment again, which basically reiterates the point I first made: https://github.com/nestjs/nest/issues/4007#issuecomment-582779510
But why should Nest not provide a solution out-of-the-box?
Because it adds to the maintenance overhead with little advantage to the framework and it really isn't necessary that the Nest team do it all.
Scott
I completely agree with @jmcdo29 and also have a https://github.com/nestjs/nest/issues/5148#issuecomment-664003442 as well. You can just create your own module with advantage of any customization you want, so you don't face any restriction or limitation from the framework itself. For me I like creating my own wrapper module as much as I like without worry any compatibility as long as you follow the Nest Module document.
Most helpful comment
Because it adds to the maintenance overhead with little advantage to the framework and it really isn't necessary that the Nest team do it all.
Scott