Matt Edelman

I think the short answer to the issue is that the "app" instance you have outside of the request lifecycle: a) is using the adaro dust engine but b) does...

Good point @aredridel. You can use [bundalo](https://github.com/krakenjs/bundalo) to resolve the localized content bundle(s), do whatever other machinations to the data model, and then use dust directly to render the email....

This use case seemingly solved, it still is somewhat troubling that `app.render` is rendered useless... Unless we add something to the documentation regarding its usage as an anti pattern.

``` js "dependencies": { "construx": "^1.0.0", "construx-copier": "^1.0.0", "construx-dustjs": "^1.1.0", "construx-sass": "^1.0.0", "dust-makara-helpers": "^4.1.2", "express": "^4.12.2", "extend": "^3.0.0", "kraken-js": "^1.0.3", "makara": "^2.0.3", "nodemailer": "^1.8.0", "nodemailer-sendmail-transport": "^1.0.0" }, ```

^^^ you can obtain the correct properties file(s) using `bundalo` (which will return them as a JSON structure) and then use `dustjs-linkedin` directly to perform the email rendering.

Agreed. I've started looking into that aspect.

Hey @gshively11 .. happy to take a look and evaluate it. if it's an acceptable risk then we can move forward

I spent some time trying to understand how to hook up the new version of uglify. I'll admit it's beyond my ability (or at least within the time I spent)...

+1

:( oh no. thanks for reporting that.