Well it's that time of the year again and as the gifts are being given out I thought that it was time to give a gift of our own: a slew of updates to a few of our open source node.js libraries. There are some breaking changes in these updates, so check out the changelogs here, here, and here. Also, you can read the rest of this post for a quick summary of what's new.

forever v0.3.1

Forever has been getting a lot of attention since I wrote about it last month. With over half a dozen issues logged in Github, I felt it was time for some updating. Some of the big changes were to internals, but there are some notable changes for the cli, mangaging log files, and spawning non-node processes (thanks substack!):

Working with Logs

'forever list' now displays the location of the logfile for that process:

  $ forever start myscript.js
  $ forever start -l mylog.log myscript.js
  $ forever list
    0 myscript.js  [24485, 24484] /tmp/forever/foreverYs3.log
    1 myscript.js  [24517, 24516] /tmp/forever/mylog.log

You can also cleanup old logfiles by using the 'cleanlogs' command, but be careful there is no going back from this:

  $ forever cleanlogs

Spawning Non-Node processes

Thanks to a contribution from substack it is now possible to spawn non-node processes with forever via nodejs code, but not from the command line. Here's a simple example from the tests:

var child = forever.start([ 'perl', '-le', 'print "moo"' ], {
  max: 1,
  silent: true,
});

Here we are spawning a Perl process to print 'moo' with a maximum of one restart.

Stopping processes by script name from the CLI

This has been a request since the day that I released forever v0.3.0 in that when I improved the CLI to allow for starting and stopping from the command-line, I decided to go with an index based system. This was because I couldn't decide on a good behavior for the following scenario:

  $ forever start myapp.js
  $ forever start myapp.js
  $ forever list
    0 myapp.js  [24485, 24484] /tmp/forever/foreverX2Y.log
    1 myapp.js  [24517, 24516] /tmp/forever/forever1e4.log
  $ forever stop myapp.js

Clearly in this scenario there are multiple instances of myapp.js running on the target system. What this will do no is stop ALL instances of myapp.js on the system so use with caution:

  $ forever stop myapp.js
  Forever stopped processes:
    0 myapp.js  [24485, 24484] /tmp/forever/foreverX2Y.log
    1 myapp.js  [24517, 24516] /tmp/forever/forever1e4.log

node-cloudfiles and node-cloudservers v0.2.0

The changes to both of our Rackspace Cloud libraries centered around a by-design issue opened about 2 months ago. That is previously by-design both libraries were designed to work with a single account at a time. This was just fine for our usage at Nodejitsu since we only run against either our test, dev, staging, or production environments in any given deployment, but didn't support for other scenarios. Here's a quick before and after for usage since these are breaking changes:

Before (0.1.x)

  var cloudfiles = require('cloudfiles');
  var example = {
    auth : {
      username: 'your-username',
      apiKey: 'your-api-key'
    }
  };
  cloudfiles.setAuth(example.auth, function () {
    // Work with Rackspace Cloudfiles from here
  });

After (0.2.x)

  var cloudfiles = require('cloudfiles');
  var config = {
    auth : {
      username: 'your-username',
      apiKey: 'your-api-key'
    }
  };

  var client = cloudfiles.createClient(config);
  // Work with Rackspace Cloudfiles from here

The above usage pattern is also the same in node-cloudservers 0.2.x as well as node-cloudfiles 0.2.x. Wanted to make sure that there was some consistency in our releases. So that's it for today, keep checking back: we'll be opening our beta up more in January 2011.