Node JS nginx & pm2 config

This is for personal reference and I make no guarantees any of this will work for you. I no longer need it, but don’t want to lose this either. Future reference, and all that.


node-gyp rebuild Error on Ubuntu 15.04 with Node 4.x.x

I’m going to start with the tl;dr version:

if you are experiencing this issue, and you have recently installed Node 4.x.x, then this is likely your issue.


Find another package, or use an older version of node for now if you absolutely must use that package.

The Longer Version

I had been trying to install “webkid-react-starterkit@0.3.1” on my Ubuntu dev box for ages last night, and spent a wasted 25 minutes again on it tonight.

The error was staring at me right in the face honestly:

It’s likely not as easy to see here, but on my terminal output, it’s colour coded and it’s rather glaringly obvious:

I went round many houses.

From trying to install contextify globally, to completely reinstalling node, to even getting down to specifying the exact version of the v8 profile I wanted ( npm install v8-profiler@3.6.2-1 ).

Nothing worked.

Anyway, it turns out it’s incompatible with this version of node all along.

NodeJS 4.0.0 only tagged as stable on 8th September 2015, and here I am running 4.2.1.

Buckle in, it’s going to be a wild ride.

Models not working in Loopback Passport Module

I’ve been having a heck of a time trying to get Passport, or more specifically, the Loopback Passport Component to work with my Strongloop API project.

I should say, this is an existing project into which I have installed the loopback passport component (npm i loopback-component-passport --save) rather than using the Loopback Passport Example – which I also have had plenty of problems with.

Today’s error was when loading the Strongloop Composer (v1.8.1), I could see my datasources, but the models were empty:


When opening up the Chrome developer tools > console, I could see this:

But Googling this error wasn’t coming up with much in the way of suggestions.

Another strange thing was that I could add in a new Model, save it, but then if I refreshed the page, it would disappear. The model itself had been created in the common/models dir. I could see the .js and .json files in my WebStorm project, and if I tried to create a new Model with the same name it wouldn’t let me. But the slc arc Composer just wouldn’t display them.

Though I cannot remember exactly how I was getting to this point, I was also infrequently seeing errors in the console, with this error message:

I’m leaving that in, in the hope that any future Googlers may save themselves some time.

My Fix

To get this working I ended up creating a brand new project (slc loopback) and then piece by piece, copying my existing project across and watching for where it broke.

It turns out it was largely the Passport module config that was breaking the project, so here are the relevant, working files:

Check your versions. Loopback changes a lot.

In the model-config.json, note the inclusion of "./node_modules/loopback-component-passport/lib/models" in the meta > sources, the UserCredential, and UserIdentity models:

Why the duplicates, e.g. User and user?

Well, you have to define the base model, and then your own model which extends the base. But both have to be defined.

This bit left me confused, so here are each of the relevant models for reference:

Once the models are displaying again, feel free to change the datasources:

Note, those are the settings created by Strongloop slc arc. If you enter them manually, using the data / fields in the manual, you may end up with duplicates – e.g. user and username.

My Loopback Passport Module Config

And lastly, and probably the most important is the server.js file.

The ordering here seems to be the most important part.

If your passport config tries to call the models before they are ready, that seems to cause a lot of problems. It sounds obvious in hindsight, but when you have a lot of things going on in your server.js file, sometimes it can be hard to see the wood for the trees.

How to get the Latest NPM Dependencies

I have been doing a fair amount of work lately with the Node.JS Loopback framework.

The more I use the framework, the more I find myself enjoying it.

I liked your dish, but…

But, there’s one thing about Loopback – and pretty much every Node development project I have worked on – that I find needlessly time consuming:

Finding the latest versions of your NPM dependencies.

Up until very recently, the way I was doing this was comically laborious.

I would open the package.json file, take a look at the installed packages:


And then… *cringe*, head over to NPMJS, manually search for each project, then take a note of the latest version:


And pop that info into my package.json file. Rinse and repeat for all the NPM dependencies in my project.

This is 2015. There has to be a better way.

And there is.

Using Node to Update Your NPM Dependencies

There’s a really useful package for keeping your NPM dependencies up to date with the very latest versions – it’s called NPM Check Updates (NCU) by Tomas Junnonen.

Straight from the ReadMe:

npm-check-updates is a command-line tool that allows you to find and save the latest versions of dependencies, regardless of any version constraints in your package.json file (unlike npm itself).

npm-check-updates maintains your existing semantic versioning policies, i.e., it will upgrade your"express": "^4.11.2" dependency to "express": "^5.0.0" when express 5.0.0 is released.


A word of caution, however.

Whilst this seems like a great time saver – and it is – be sure to have some way of checking (ahem, tests) that the latest and greatest packages haven’t inadvertently completely broken your project.

A great example of how this can go wrong would be in the screenshot above. Here, I pulled in the Loopback Passport Example project, ran the ncu utility, and promptly ended up with a project that won’t even start.

As a side note, if you are wanting to add tests to a Node project, I highly recommend Tape. Initially, it’s a little different to normal testing libraries, but having taken the plunge, I really like it.