Node 0.11.16 and io.js 1.1.0
Node 0.11.16 is out, bringing an update to OpenSSL, npm, and some core modules: url, assert, net, and url. The util.inspect patch is interesting because errors generated by the assert module now get formatted with
util.inspect instead of
JSON.stringify. The idea behind this patch was to avoid errors due to circular references.
io.js 1.1.0 also has this patch, but there are again lots of unique commits that aren't in Node. Using my limited Git forensic skills, I tried to compare commits between both projects, but I haven't found a good way to do it yet. This is what I tried:
git clone https://github.com/joyent/node cd node git remote add iojs https://github.com/iojs/io.js git fetch iojs git checkout iojs/v1.x -b iojs git branch --contains df48faf git cherry -v origin/master iojs
I noticed that
git branch showed a commit that I know is only in iojs actually in the iojs branch I made based on the
v1.x branch from
cherry shows commits that are in both Node and io.js, so I'm not sure what the best way of tracking unique commits to each project.
I use the async module all the time without really worrying too much about performance, but Shunsuke Hakamata sent in neo-async (GitHub: suguru03/neo-async, License: MIT, npm: neo-async), a drop-in replacement for async created by Suguru Motegi which aims to improve performance.
The benchmarks have been made on major browsers, Node (stable), and io.js. Not every method is implemented, but the results the author has generated look compelling. If you take a look at the
async.waterfall benchmarks, async appears to get slower based on the number of tasks, while neo-async stays flat.
Testing Node Unit Tests
Jani Hartikainen sent in an article about HTTP testing with Node. It covers Mocha, Sinon, and uses stubs for the built-in http module:
Let's start by adding a test that validates the get request handling. When the code runs, it calls
http.request. Since we stubbed it, the idea is we’ll use the stub control what happens when
http.requestis used, so that we can recreate all the scenarios without a real HTTP request ever happening.
To make sure the expected data is written into it, we need a way to check
writewas called. This calls for another test double, in this case a spy. Just like real secret agents, a spy will give us information about its target – in this case, the
You could use this as the basis for faking requests to third-party APIs in your tests.