Videos from Sydney JavaScript UG, 17 July 2013

Last month I started a new habit, recording SydJS usergroup videos. Although there are not so many views of these on YouTube, I got a call from a friend who can’t make it to the gathering and thinks the video are useful, so, I’m continuing with them…

Here are the videos for this month’s gathering. Pro-tip: Make sure to switch video quality to 720p for best experience. The video quality button is one of the left buttons next to full-screen button.

Ben Schwarz – Built an application, and will show you what he learnt

On responsive design and other real-world implementations

Don Nguyen – Server Side JavaScript building a game right before your eyes

A Node.JS session by the author of the “Jump Start Node.js” book

John Allsopp – Building an HTML5 security camera LIVE in under 15 minutes

Been amazed by the capabilities available on so many regular laptops today

NodeJS On Windows – Choosing Components To Install

In case you didn’t know, NodeJS v0.10.0 has been recently released, a number of interesting changes were mentioned in the blog post, mainly around making some core APIs easier to use, which required several in changes in the codebase to support, and caused some interesting performance characteristics changes .

I couldn’t wait, so, I looked for the Windows x64 installer, downloaded and ran that, the usual Next .. Next .. installer, well, until I saw this installer step:

Node JS Custom Setup Step

Although I can’t think of a scenario where I’d deselect any of these, just the fact that I could clearly see and choose what Node installer will do was great. I have an interest in the NPM part installation behaviour you know, this screen gets me pretty close to more understanding and utilization of this understanding, which I may blog about later.

Great job, Node team :-).

Node JS On Windows: Unable To Update NPM? A Possible Reason & Workaround


How I Hit This

I was playing with Node installation, and had a problem installing a certain Node package (which happened to be the first package I tried). I googled the problem and what seemed relevant problem was solved by updating NPM (Node Package Manager). I went to NodeJS website, downloaded the latest Node for Windows (v0.8.14 as of this writing), and tried again, same problem.

I then went to NPM git repository, and checked the latest git version (now that I tried to click download on NPM official site, I see it only redirects to NodeJS website). The latest version mentioned in recent commit comment (2 days old as of writing) was v1.1.66. A quick check

npm version

showed me that I have NPM v1.1.65, not v1.1.66.

So, how does NPM expect you to update it? At first it sounded very simple:

npm update npm -g

This treats NPM itself as a package, and tries to update it globally. Easy stuff, right? Well, expect that when I checked for NPM version again, I found that it was still v1.1.65!

The Problem

Looking at the output of the update command, I noticed that it downloaded the update to


It sounds like "global" in NPM, at least Node on windows (but I assume other versions too), means global within the same user profile (Under %APPDATA% folder, $ENV:APPDATA if you are using PowerShell). Not a problem though, right?

Well, for some reason, writing Node in console or PowerShell was actually calling the one that lives in another folder, in Node program files folder:

C:\Program Files\nodejs

Note that this is not under "node_packagesnpm" under Node, it’s directly in the root of Node’s folder.

The Workaround

Well, I hope I;m not disappointing you here, the fix was a bit obvious for me, I copied all contents of the "npm" folder I listed upwards, and pasted all the content of this folder (but not the folder itself, I went inside the folder, selected all child files and folders, and copied these), and pasted this into the Node program files folder also shown above (after taking a backup of that folder of course).

Checking for NPM version afterwards reported the correct version 1.1.66. This allowed me to get back to the original problem I was trying to solve, which interestingly wasn’t related to Node version at all, that’s why I didn’t mention a lot about it here.

Digging More Into The Problem

After everything is working, while writing this post, I went writing:

npm update npm -g

and even

npm install npm -g

out of nothing but getting crazy, anyway, I checked what I’ve got now and noticed the following:

  • The "npm" folder under %APPDATA% has an "npm.bat" that tries to call the version it installed under %APPDATAnpmnode_packagesnpm".. Which means, whenever this file called, it should call the version inside my %APPDATA% without having to copy it anywhere else.
  • The "npm" folder under %APPDATA% has been added to my environment %PATH%. This sounds like great, it should just work, right? Well, not really, follow on.
  • The backup I still got of the "nodejs" folder inside Program Files, contained another "npm.bat" file. This file was trying to load NPM from the "node_modulesnpm" folder under "nodejs" program files folder.
  • Of course the "nodejs" folder is already in my %PATH% as well. It’s also there BEFORE the "npm" folder under %APPDATA%. This means, executables from "nodejs" folder will be executed first.

Now the problem is more obvious, NodeJS was trying to do the right thing in the %APPDATA% folder, but for some reason, the version in program files folder was still there screwing what it was trying to do. It’s always called first, and there is no way to update it except by updating NodeJS itself (which may sound y design, except NPM thinks it’s updateable by just dropping a new version in my %APPDATA% folder).

Going Forwards

This analysis suggests that it may be even possible to delete the NPM specific files and folders from "nodejs" program files folder, except I think leaving a copy there is a bit safer for whatever future thing that may expect them in that path.

I can actually think of good reasons why they are there, like usage by non-interactive user accounts, like service/IIS accounts or so. I don’t expect Node and NPM to be out of sync for long anyway. Likely just a few days or so.

Could It Be An Older Node Version Issue?

I couldn’t resist the thought this may have been fixed already. To test this, I have uninstalled Node completely, renamed the "nodejs" folder to something else, and reinstalled v0.8.14 on a clean "nodejs" folder the installer created by itself.

The default "NPM" files and folders were still there. This made me sure that this wasn’t just a remaining of whatever old Node version I had before. Again, there is a possible good reason why they are there anyway.