Node.js and Node Package Manager

Node.js is a platform that uses Google Chrome's JavaScript engine. This means that we can create server applications using JavaScript. We do not need an in-depth knowledge of everything on Node.js, we only need it to be installed. Node.js binaries are packaged for all the major platforms at http://nodejs.org/download/.

We will use npm (also known as Node Package Manager) to install all the libraries that we are going to use. Most languages/platforms/frameworks move to a managed packaging system. This will be familiar if you have ever used Python's pip with virtualenv, Debian's apt-get, or Microsoft's NuGet, to name a few. Managed packaging allows developers to explicitly define what dependencies your application requires. We will install almost all the Node packages locally. This allows us to install and test new dependencies separately without creating conflicts on the system. By default, npm installs the packages to a folder named node_modules in the root of our project. When a package is used in a file, Node will check this directory for the package. The code that accompanies each chapter will not have the node_modules directory included, but it will have the file that defines what is needed. When we install something globally, we will use the –g flag for npm. This installs the packages to a central node_modules directory so that every Node project can use the package. If you have built a Node.js project before, this should not be new. I will write out the commands for anyone that has not used npm.

Node packages are very notorious for having fast release cycles, which means that by the time you have read this, some of the packages you will use might be of a different version. There are a few ways to combat this. We can use npm shrinkwrap, which will explicitly define each package and all its dependencies. Another way, is to include all the dependencies into source control, so we are completely sure what package and version is installed. I will list out the versions I have used, so that you can install the same versions. As an example, Express has already gone through a major version upgrade (from Version 3.x to 4.x), which was not completely backwards compatible.

The following are the versions that we will use:

• body-parser: 1.4.3
• connect: 3.0.2
• cookie-parser: 1.3.2
• csurf: 1.3.0
• ejs: 0.8.5
• express: 4.6.1
• express-partials: 0.2.0
• express-session: 1.6.5
• redis: 0.10.1
• connect-redis: 1.4.7
• connect-flash: 0.1.1

To ensure that these are the versions installed, you can create a file in the root of the project named package.json. The file should look similar to the following code:

{
  "name": "NodeChat",
  "version": "0.0.0",
  "main": "app.js",
  "scripts": {
    "stop": "echo not implemented",
    "start": "node ./app.js"
  },
  "dependencies": {
    "ejs": "0.8.5",
    "express": "4.6.1",
    "express-partials": "0.2.0",
    "redis": "0.10.1",
    "connect-redis": "1.4.7",
    "connect-flash": "0.1.1"
  }
}

Tip

Downloading the example code

You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

The package.json file defines attributes about our project using JSON. The key property that we are concerned with here is dependencies. We define each one in the dependency object along with the version. Note that each dependency is pinned to a specific version. We can add a line to install Express 4 or above as follows:

"express": ">=4.0.0"

The issue with this is that we will not know what version we can get. Always prefer explicit dependencies to implicit ones.

We can then install the required packages by running the following command:

npm install