hapi-mandrill

HAPI plugin that exposes mandrill api - used to send transactional emails.

(C) 2014 Martin Wawrusch

HAPI plugin that exposes mandrill api - used to send transactional emails.

The rational behind this is that every single hapi app I created needs transactional emails, and it always involves plumbing code. With this module I provide the most common usecase with a well defined signature, and also expose the mandrillClient.

The key and templateNameMapping parameters are optional, but without a key nothing gets sent (useful for testing).

 
hapiMandrill = require 'hapi-mandrill'
 
pluginConf = [
    plugin: hapiMandrill
    options:
      senderName: "John Smith"
      senderEmail: "john@smith.com"
      key : null # Keep null for testing
      templateNameMapping: 
        "from" : "toInMandrill"
]
 
server.pack.register pluginConf, (err) ->
  #...
 
 
fnCallback = (err,result) ->
  # Do some stuff when done.
 
plugin = server.pack.plugins['hapi-mandrill']
 
plugin.send("Angelina Jolie","angelina@jolie.com", {some: "payload"},"Hello Angelina","angelina-template", fnCallback)
 

The plugin logs successful and failed sends. NOTE: If you want to disable this, or want different log tags let me know and I will make it customizable.

Mandrill templates are often managed by third parties, you don't want them to break a core functionaly without testing it first yourself. For that reason, you can define internal template names and transform them to whatever you want to use in mandrill. To do so, set the 'templateNameMap' object to internal : external pairs. If none is defined, or a key is not found it will be passed verbatim.

plugin = server.pack.plugins['hapi-mandrill']
 
plugin.mandrillClient # Note this is null if you do not pass a key in options
plugin.send(...)
plugin.templateNameMapping = {...}
 

and additionally

  • Check out the latest master to make sure the feature hasn't been implemented or the bug hasn't been fixed yet
  • Check out the issue tracker to make sure someone already hasn't requested it and/or contributed it
  • Fork the project
  • Start a feature/bugfix branch
  • Commit and push until you are happy with your contribution
  • Make sure to add tests for it. This is important so I don't break it in a future version unintentionally.
  • Please try not to mess with the package.json, version, or history. If you want to have your own version, or is otherwise necessary, that is fine, but please isolate to its own commit so I can cherry-pick around it.

Copyright (c) 2014 Martin Wawrusch