The JavaScript blog.


npm libraries node webapps modules deployment

Node Roundup: Rozu, environmentalist, package.js

Posted on .


Rozu (GitHub: avoidwork/rozu, License: BSD-3-Clause, npm: rozu) by Jason Mulligan is a webhook API server that uses io.js or Node, MongoDB, and Redis. MongoDB is used for persistence, and the Redis pub/sub API is used for inbound events.

It's built with tenso for the REST API, and keigai for data storage with MongoDB. It can both send and receive webhook events. To send events, you make a POST to /send with a logged in user, and to make it receive a JSON payload you use /receive. Receiving events uses a token, so it's pretty easy to use it with sites like GitHub.

Once you've installed it you can create an account by making a GET request to /register. If you visit / (whether signed in or not) you'll get a list of API methods.


Alexander Christie has written a blog post about dealing with environmental variables in web applications. Rather than having a list of variables that you have to remember to set on every server for each dependency, his solution is based on using a Node command-line tool called environmentalist (GitHub: AJCStriker/Environmentalist, License: MIT, npm: environmentalist).

The problem is that we use several different packages to build our application, taking full advantage of the awesome NPM private modules that were recently released. The problem was that it has become increasingly hard to keep track of what environmental variables were required to make the project function, or were just generally available, because they were all being accessed at different levels of the applications dependency tree.

With environmentalist, you define a JSON file that specifies each environmental variable:

    "description": "Used to compute the password hash of users",
    "default": "ABCDEFGHIJKLMOP",
    "required": true

Because you can include a description it's already useful because in my experience most people export (or heroku config:set) and forget about it later. I also like the fact you can set a default value and the required state. The name is the only required field, so if the values are obvious and self-documenting then you can keep things simple.

When you run environmentalist in the command-line, you'll see a table that shows all of the environmental variables in the current package and its dependencies, which means you can construct projects from submodules with environmentalist JSON files and it'll dig them all out.


If you've created a Node application but you want to support plugins, what to do you? package.js (GitHub: s-a/package.js, License: MIT and GPL, npm: package.js) by Stephan Ahlf is designed to allow you to open up your project to plugin developers through npm or other package managers.

It allows you to load modules from a set of paths, and then ensure each module has a property (expectedPackageIdentifier) in its package.json. It's a small module with unit tests and an example in the readme.


libraries ui deployment articles

Slideout.js, Shipit vs Flightplan

Posted on .


Slideout.js (GitHub: mango/slideout, License: MIT, npm: slideout) by Guille Paz is a touch-based slideout navigation menu for mobile applications. It doesn't use any dependencies, and the markup is sensible. It has CSS transforms and transitions, and uses native scrolling.

The markup is based on HTML5 tags, so you can define the navigation panel with a nav element. It works in most browsers, and the base version of IE is 10.

The JavaScript API uses a Slideout constructor function, and it accepts options for animations, duration, and the necessary DOM elements.

One nice thing about this library is there are lots of ways to install it: npm, spm, bower, and component are all supported.

Shipit vs Flightplan

I've written about Shipit and Flightplan, but I haven't yet used both deployment solutions for anything serious. John Munsch has written a long post about his experiences using both Shipit and Flightplan with a DigitalOcean server:

I did everything from start to finish myself and I felt duly proud about having built something from scratch and launched it no matter how small it was. The tasks covered by my scripts were: initial machine configuration, updating of Ubuntu (mainly to get security fixes), deployment, and creating a SSH shell to the remote server.

Using a cheap VM can be very affordable if you want to host your own email, web services, and maybe use it for IRC. Deployment is naturally more work than something like Heroku, but Shipit and Flightplan can really streamline things.

John's article compares the pros and cons of each library, and he's included the scripts he used for deployment.


libraries deployment node modules

Deploy Apps with Flightplan

Posted on .

If you saw my post about Shipit yesterday, then you might be interested in trying out Patrick Stadler's module, Flightplan (GitHub: pstadler/flightplan, License: MIT, npm: flightplan). Flightplan is a deployment library that is more influenced by Python's Fabric than Ruby's Capistrano. It can also be used for general administration tasks as well.

If you want to use it, you'll need a flightplan.js file. This defines the deployment targets, like staging and production, and contains the local and remote commands to run. I like the syntax of the plans because they're based on simple JavaScript callbacks with locally scoped variables rather than any kind of magic globals:

plan.remote(function(remote) {  
  remote.log('Move folder to web root');
  remote.sudo('cp -R /tmp/' + tmpDir + ' ~', {user: 'www'});
  remote.rm('-rf /tmp/' + tmpDir);

  remote.log('Install dependencies');
  remote.sudo('npm --production --prefix ~/' + tmpDir
                            + ' install ~/' + tmpDir, {user: 'www'});

  remote.log('Reload application');
  remote.sudo('ln -snf ~/' + tmpDir + ' ~/example-com', {user: 'www'});
  remote.sudo('pm2 reload example-com', {user: 'www'});

Groups of commands like this are called "flights". You can run subsets of flights, which are known as tasks:

plan.local(['deploy', 'build'], function(transport) {});  
plan.remote(['deploy', 'build'], function(transport) {});  

The transport argument for flights contains a runtime property that lets you query the target, hosts, and options. You could use this to print extra debugging information based on options passed to the task. This design means you could split flights into separate modules, which might be useful if you need to orchestrate the deployment of a collection of separate apps or microservices.

Transports also have some handy utility methods. You can rsync files with the transfer method, like this: local.transfer(['file.txt', '/tmp/foo'). If you want to ask questions during a script you can use transport.prompt -- this might be useful for restricting deployment to specific employees without having to store passwords in your repository. There's also a waitFor method that can be used to wrap asynchronous operations.

The fact it supports synchronous, blocking operations means you can write lists of commands more like the way shell scripts operate. I assume this is how most devops and sysadmins prefer to work, so Flightplan might make more sense to them rather than dealing with asynchronous APIs.

To make this possible Flightplan uses fibers. Here's a snippet from lib/flight/remote.js:

var execute = function(transport) {  
  var future = new Future();
  new Fiber(function() {
    var t = process.hrtime();
    logger.info('Executing remote task on ' + transport.runtime.host);
    logger.info('Remote task on ' + transport.runtime.host +
                ' finished after ' + prettyTime(process.hrtime(t)));
    return future.return();
  return future;

Patrick notes that Flightplan now supports cloud providers (including EC2 on Amazon and DigitalOcean), so you can easily define the remote hosts which may change with large projects on such services. In a way I think this makes Flightplan a little bit like Puppet and Chef. If you still haven't found your perfect deployment solution, or if you have to maintain remote servers, then you should give it a try.


libraries deployment node modules iojs

Node Roundup: 0.10.36, io.js 1.0.4, Object.observe, Shipit

Posted on .

Node 0.10.36, io.js 1.0.4

The latest stable release of Node, 0.10.36, came out earlier this week. The changelog is short with just three bullets, but one thing that stands out is "v8: don't busy loop in cpu profiler thread". The commit for this is 6ebd85:

Before this commit, the thread would effectively busy loop and consume 100% CPU time. By forcing a one nanosecond sleep period rounded up to the task scheduler's granularity (about 50 us on Linux), CPU usage for the processor thread now hovers around 10-20% for a busy application.

In io.js, 1.0.4 has been released. I noticed in the changelog that there's a patch for V8 and ARMv6, so io.js should work again on platforms like Raspberry Pi.


It seems like I've been writing about a lot of frameworks that use ES6/7, but sometimes you just want a specific polyfill rather than an entire framework. A new polyfill that Massimo Artizzu sent me is for Object.observe (GitHub: MaxArt2501/object-observe, License: MIT, npm: object.observe, Bower: object.observe), which you can use with Node and browsers.

The readme explains the basic usage, but there's also more detailed documentation. This also explains the two versions of the API:

If you don't need to check for "reconfigure", "preventExtensions" and "setPrototype" events, and you are confident that your observed objects don't have to do with accessor properties or changes in their descriptors, then go for the light version, which should perform reasonably better on older and/old slower environments.

In Node 0.10.x, you can use it like this:

if (!Object.observe) require('object.observe');  

This will avoid loading it when your version of Node gets Object.observe in the future.



Greg Bergé sent in Shipit (GitHub: shipitjs/shipit, License: MIT, npm: shipit-cli), a deployment tool. It can use SSH to sign in to a server and run scripts, and it handles multiple environments so you can create settings that will work for production, staging, CI, and so on.

It has an event-based API with tasks, in a style that reminds me of Grunt and Gulp. It uses plain old SSH and rsync under the hood.

Shipit recently got lots of attention because Ghost uses it. I haven't been able to find an exact reference to Shipit in Ghost's source, so it's presumably used for deploying their commercial hosted solution. However, I actually thought Shipit might be useful as part of Ghost's open source stack, because it would help support people who download Ghost and deploy it to their own servers. It would be interesting to discover more about the Ghost connection.


testing deployment node modules mocha

Node Roundup: 0.6.14, Mocha 1.0, ncluster, ENVy

Posted on .

You can send in your Node projects for review through our contact form or @dailyjs.

Node 0.6.14

Node 0.6.14 was released soon after 0.6.13. This release includes bug fixes and updates npm to 1.1.12.

Mocha 1.0

Mocha 1.0 has been released. There's now a GitHub-flavoured Markdown reporter, and JavaScript "compilers" are now supported with mocha --compilers coffee:coffee-script.

An API has also been added, so it's possible to programatically create tests:

var mocha = new Mocha;  



ncluster (npm: ncluster) by Ben Murphy is a zero-downtime clustering solution. It'll reload the application when a SIGHUP is issued, and gracefully quit when SIGQUIT is sent.

Ben has designed it to be used with Capistrano. He's also created a Node/Ubuntu Vagrant deployment solution with instructions for deploying his demo app to a virtual machine (nodejsvagranthelloworld).


ENVy (npm: envy) by Elio Capella Sánchez is a small module for managing JSON settings files. It'll use require to load a file called config.json in the project's root directory.

It also uses a convention for automatically determining the environment and loading the appropriate properties. Given a JSON file like this:

  "environment": "development",

  "development": {
    "test": "Development property"

  "production": {
    "test": "Production property"

Then require('envy').config will load the development settings, so config.test will return "Development property".