

Your first Node.js module - c_t_montgomery
http://cnnr.me/b/2012/05/your-first-node-dot-js-module/

======
tg3
The error that is thrown towards the end of this example should probably be
passed back to the callback as an argument (e.g. callback(error, result))
instead.

Throwing errors in an asynchronous context can have messy results for trying
to handle them. <http://benno.id.au/blog/2011/08/08/nodejs-exceptions> is a
good explanation.

~~~
c_t_montgomery
Great point. I'll update the gist. Thanks for bringing this up!

------
secoif
It should also be pointed out you rarely need to edit the package.json
manually:

npm init: Prompts for basic/common package.json entries

npm install --save: Install a module and place into dependencies

npm install --save-dev: Install a module and place into dev dependencies

npm install --save-optional: Install a module and place into optional
dependencies

[http://blog.timoxley.com/post/22371787222/handy-new-
options-...](http://blog.timoxley.com/post/22371787222/handy-new-options-for-
npm-install)

~~~
c_t_montgomery
I was debating whether or not to put it in there. Since Isaac mentions it in
his article that I link to, I figured most people would see it there. Very
valid point though. I think I may edit the post and put it up there. Thanks!

~~~
c_t_montgomery
...and the post has been updated. Thanks again.

------
aeurielesn
Just for the record, I think you should have used `encodeURIComponent` instead
of `encodeURI`. And in `exports.info` as well.

~~~
c_t_montgomery
Ah great catch. I just changed it. Thanks!

------
phase_9
I liked the part where you encouraged the developer to think about how the API
will be consumed by the end user; however even a brief mention of some BDD /
Unit tests here would have been nice (:

~~~
c_t_montgomery
I agree it would have been nice. Apologies for not including it.

------
tferris
Slightly OT: does anyone have a good explanation for module.exports vs exports
and for the expression 'exports = module.exports = someFunction' often found
in modules?

~~~
strager
Reassigning the `exports` variable does not change the return value of
`require`.

The return value of `require` is `module.exports`, which may be reassigned.

Initially, the global `exports` variable is set to the same value as
`module.exports`. Writing `exports = module.exports = ...` ensures they have
the same value as you would expect.

~~~
tferris
> Writing `exports = module.exports = ...` ensures they have the same value as
> you would expect.

But where should they have the same value? I thought require returns just
module.exports if it exists and ignores exports.

~~~
secoif
'this' is also the same as exports. Initially, they all have the same value,
they all point at the same object. If you assign module.exports to a new
object (vs simply adding properties to the existing object) it will ignore the
value of exports and this.

It's incredibly confusing and they should have just picked one way to export
data, instead of three.

