Node.js v 4.0.0 was just released. This is a long-awaited release representing the healing of the schism in the Node.js community created when the io.js project forked Node.js. That had been done over a disagreement about the policies and maintainership of Node.js. Joyent had been in control of the project (because Ryan Dahl had been employed by Joyent) and not all in the community liked the decisions made by Joyent. They instead forked the project to create io.js, and implemented a bunch of useful ideas for example to adopt the latest-and-greatest version of the V8 JavaScript engine in order to get all the modern ES6 goodies.
A few months ago the Node.js and io.js teams came to an agreement. A new Foundation would be created, co-sponsored by a bunch of companies, to oversee Node.js. The workspaces would be merged so that there'd be just the Node.js workspace, and not Node.js/io.js as separate workspaces. And so on.
Releasing Node.js 4.0.0 means the community reached that milestone of merging the repositories and issuing a stable release.
For the rest of us that means we now need to test compatibility of our code with Node.js 4.0.0.
That's what I set about doing earlier today, checking my code for compatibility. It was great to run AkashaCMS to rebuild one of my sites while using 4.0.0, and see it work flawlessly. But then I set about checking the code for my book, Node Web Development, and ran into a problem.
Some of the example code uses the SQLite3 and LevelDOWN database engines. Unfortunately both of those engines failed. But I figured out what to do instead.
For the purpose of checking compatibility, I'd installed Node.js 4.0.0 in /usr/local/node-v4.0.0-linux-x64. This is Ubuntu, and I have Node v0.10.x installed as a regular system package. That package is still installed as the official Node binary for the system. I didn't want to change that, and instead wanted to simply kick the tires of 4.0.0.
To run the code for my book, I did this:
$ rm -rf node_modules/
$ /usr/local/node-v4.0.0-linux-x64/bin/npm install
$ /usr/local/node-v4.0.0-linux-x64/bin/node app.js
For most code this worked. However, the code which relied on SQLite3 or LevelDOWN failed. It was puzzling, and I even filed some bugs with those two project teams.
In one case, SQLite3, they'd been working on an update for 4.0.0 compatibility and had recently published an update for that purpose. But the LevelDOWN guys gave me an idea to do this:
$ export PATH=/usr/local/node-v4.0.0-linux-x64/bin:${PATH}
That then let me run the commands this way:
$ rm -rf node_modules/
$ npm install
$ node app.js
Now my code works perfectly with no change. This is code that'd been written back in 2013 and had been published, on paper, in my book, so the code had better work as it's written in the book.
What's different from changing the PATH as I did? It would mean that internally to "npm install" there's a dependency on running a command line "node something-or-other" to install some things. In particular, SQLite3 and LevelDOWN both build platform-specific binary modules and therefore npm has to invoke the correct build tool.
By changing the PATH, I've ensured that when npm invokes a command line tool it's invoked relative to the correct PATH variable.
The tip: Go ahead and unpack the Node.js 4.0.0 distribution in a secondary location like this. Make sure to prepend that location to your PATH variable.