Awesome work so far! I'm migrating my keystone 3.x project to the 4.x beta. These are two quick features that I think could ease migration and make code syntactically simpler. I'll happily submit PR's for each of them. They could be set as environmental variables or in a config file that keystone-email looks for. If we go with the config file option, we could also add default locals.
A) Allow a default option for transport to be set as an environmental variable Something like process.env.transport, so we can declare:
new Email('templatepath.ext')
instead of:
new Email('templatepath.ext', { transport: 'mailgun' })
Which would be especially useful in projects like mine, where I have 17 email templates. Specifying a transport could override process.env.transport.
B) I think this feature is less useful. I'd like to allow a default template path. I've had to prepend templates/emails/ to all of my email templates. I would have preferred to set this in a configuration file.
Hi!
Awesome work so far! I'm migrating my keystone 3.x project to the 4.x beta. These are two quick features that I think could ease migration and make code syntactically simpler. I'll happily submit PR's for each of them. They could be set as environmental variables or in a config file that keystone-email looks for. If we go with the config file option, we could also add default locals.
A) Allow a default option for transport to be set as an environmental variable Something like
process.env.transport, so we can declare:instead of:
Which would be especially useful in projects like mine, where I have 17 email templates. Specifying a transport could override
process.env.transport.B) I think this feature is less useful. I'd like to allow a default template path. I've had to prepend
templates/emails/to all of my email templates. I would have preferred to set this in a configuration file.Thanks for your consideration!