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.<p>Throwing errors in an asynchronous context can have messy results for trying to handle them. <a href="http://benno.id.au/blog/2011/08/08/nodejs-exceptions" rel="nofollow">http://benno.id.au/blog/2011/08/08/nodejs-exceptions</a> is a good explanation.
It should also be pointed out you rarely need to edit the package.json manually:<p>npm init: Prompts for basic/common package.json entries<p>npm install --save: Install a module and place into dependencies<p>npm install --save-dev: Install a module and place into dev dependencies<p>npm install --save-optional: Install a module and place into optional dependencies<p><a href="http://blog.timoxley.com/post/22371787222/handy-new-options-for-npm-install" rel="nofollow">http://blog.timoxley.com/post/22371787222/handy-new-options-...</a>
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 (:
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?