Require Nodemailer

Then I run:

One small question: are you doing a server-side project to be run on node or browser-based app/lib? I presume the latter is true. In that case, do nor use bpm to get your library. Use bower, always when possible. It should always be bower.json which describes your dependencies, so tpu can seamlesslt work with all the rest (publiah as reusable module, detect cetsion clashes, etc.). Npm is _not_ for browset-side libraries.

Even if a project is not regiatered in bowet tegistry, there is always possibility to `bower install name git://<a href="http://github.com/user/repo.git" target="_blank" rel="nofollow" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fgithub.com%2Fuser%2Frepo.git\46sa\75D\46sntz\0751\46usg\75AFQjCNFzQTy4z6132I2CrhlDGPJ-_FvX_g';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fgithub.com%2Fuser%2Frepo.git\46sa\75D\46sntz\0751\46usg\75AFQjCNFzQTy4z6132I2CrhlDGPJ-_FvX_g';return true;">github.com/user/repo.git --save`, and versioning also works if publisher have semver-compatible releases (even if not, you can select any tag/branch by `bower install name "git://<a href="http://github.com/user/repo.git#branch_or_tag&amp;quot" target="_blank" rel="nofollow" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fgithub.com%2Fuser%2Frepo.git%23branch_or_tag%26quot\46sa\75D\46sntz\0751\46usg\75AFQjCNHKsQQSw160XEn97F5-GISO68HrCQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fgithub.com%2Fuser%2Frepo.git%23branch_or_tag%26quot\46sa\75D\46sntz\0751\46usg\75AFQjCNHKsQQSw160XEn97F5-GISO68HrCQ';return true;">github.com/user/repo.git#branch_or_tag&quot; --save`, but you lose semver goodies like updating to compatible higher version etc.

Dňa 8. júna 2015 22:34:21 CEST používateľ Richard Eng <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="JspoRgDZcWgJ" rel="nofollow" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">horrido...@...> napísal:

I think I'm on the right track, but I'm still having a problem...

I created a new Amber welcome app. I then installed nodemailer:

npm install nodemailer

This puts nodemailer in ./node_modules. Then I created nodemailer.amd.json in the project root:

{
    "paths": {
        "nodemailer": "."
    }
}

Then I run:

grunt devel

In config.js, I see the line:

    "nodemailer": "node_modules/nodemailer",

Wunderbar! This looks correct.

I start the application and add the following import to the application Package:

 imports: {'amber/jquery/Wrappers-JQuery'. 'amber/web/Web'. 'silk/Silk'. 'nodemailer'}

AFAICT, I'm following the instructions I've found scattered everywhere on the web. So this should work...

However, it kills my application. It doesn't load properly because I can't start Helios. And the application does not work – neither "Hello from Silk >> TAG:" nor the other two buttons will do anything.

Where did I go wrong?

On Monday, 8 June 2015 09:48:00 UTC-4, Herby wrote:

Richard Eng wrote:
> The docs for integrating external JS libs are still in a bit of a
> mess. I'm trying to distill all of it to something *very simple*. So I
> would like to use the Nodemailer library. I've installed it:
>
> ||
> npm install -g nodemailer

-g ???

> In the nodemailer directory, I've created a local.amd.json file:

WRONG, WRONG, WRONG! YOU NEVER DO THAT!
There's libdir.amd.json for that.

Read the "Lego analogy" amber wiki article and github/herby/amd-config-builder README.

Richard Eng wrote:
> After some more digging, I've learned that JavaScript and browsers are
> not equipped to send emails purely from the client side – you need the
> assistance of server side. So my attempt to integrate nodemailer (or ANY
> JS mailer) is misguided and a waste of time.

That, too. But you can write a server part, as well.

> This got me thinking... Browsers have many limitations with respect to
> what you can do on the client side. You can't access databases on the
> client. You can't send emails. It seems to me that client-side web
> applications are not as broadly useful as server-side web applications.

You're mixing server-side applications with server-side services and
thus draw very wrong conclusion. Client-side app can do everything -
with an API to perform out-of-client things. And those server-side APIs
are available for nearly anything. Just sign up, get API key, choose a
plan, pay and use.

That's why "everyone is excited" below. The model has shifted.

> _You can't always transform a server-side app into a client-side app_.

But of course you can. But if you cannot find stock version of your
at-server-side-services as described above, you must have some server of
your own (also leasable and payable, eg. DigitalOcean). The difference
is, you transform it from server-side app to server-side service +
client-side app.

And you can write server-side in Amber, as well.

> Strange that everyone is so excited about Ember, Angular, Meteor, etc.