In this article, I will show how you can set up a Node.js environment on Windows 10, and I’ll checkout and run the project I'm currently working on (which depends on koa, pg, amqplib and other modules).
Note, that the primary focus right now is just setting up a developer environment for a Node.js project, not running one. I will cover deployment to Azure later, but that is beyond the scope of this post.
Developing with Node.js on Windows used to be pretty cumbersome, but it's much better now than it was a year or two ago. This is the reason why we had such a hard time choosing between Windows 7 and Windows 10 as a topic of this post.
While 7 is still pretty popular and 10 had some bad press (due to metrics and extensive data collection), we decided to go with Windows 10 this time, because having an up to date operating system is crucial for security reasons.
In this tutorial we will use the newest tools and applications available (and use the 64bit version of them). I know that this is not always possible in corporate environments, but it is important not to let your tools fall behind.
Everything we install will be done natively. I would not recommend Cygwin for Node, and while VirtualBox is free, I always had problems with running a Linux VM on a Windows machine.
Step 1: Install Git
First, let's install Git. Use the default settings; they are quite sensible.
I usually have a Projects folder in my home directory. To set it up, right-click on the folder, select "Git bash here" and check git's version with
This is a nice bash environment, so feel free to create a .bash_profile, which is going to be executed when you open a bash window. This is not a cmd.exe window, so check out the Options (click on the icon in the upper left corner). You can paste text into the window with the middle mouse button (just like on popular Linux terminals).
Step 2: Install Node.js on Windows 10
Download and install Node.js. Use the LTS version.
I don't recommend installing multiple versions side by side since the node version manager (NVM) does not officially support Windows - still, there are alternatives like nvm-windows or nodist. Even on other systems, installing node utilities globally with different versions seems like asking for trouble.
Step 3: Update npm
Node comes with npm, the package manager which should be available after installing Node.js.
Open a bash shell and check the versions with
npm --version. If npm is 2.x, then you should upgrade it to version 3, which solves many problems (the most important for us is the way it handles peer dependencies). Search for Power Shell in your start menu, run it as Administrator and follow these three steps.
Step 4: Install Visual Studio and Python
Node packages usually depend on packages with native code, so you have to install Visual Studio.
Node-gyp is a wrapper around Python GYP (Generate Your Projects), a tool that can generate project files for Gcc, XCode, and Visual Studio. Since the de facto method of Windows development is via Visual Studio, that's the supported one.
Install Python (version 2.x)
As you can see, you will need Python, so download the 2.x branch for x64, and install it. You can go with the default settings, plus select the "Add to path" option. This will add the Python binary to the global path, meaning you will eventually have to log out and log back in.
As a next step, go to the environment variables settings (in System, Advanced settings) and add GYP_MSVS_VERSION=2015 to the global ones, since the next step will be the Visual Studio 2015 install.
Install Visual Studio (VS2015)
VS2015 works fine with x64 Node.js, unlike the pre 2012 versions. For a while, we are going to follow the Node-gyp tutorial for Windows 10.
Unless you already have a full VS on your machine, download the Visual Studio 2015 Community Edition, choose custom install and select the whole Visual C++ branch (without XP support); from tools choose Windows SDKs. In case anything goes wrong during the install, you can go to Programs and Features, select VS2015, choose change and then repair.
The gyp install howto also mentions the Windows 7 SDKs, but we installed the Win 8 one above, so hopefully that is not going to be needed.
Step 5: Install Package Dependencies
Currently, I'm working on the alerting microservice in Trace, so I'll do an
npm -i to install our package dependencies. As a result I’m getting this back:
Fsevents is an optional dependency and is for OSX only; this is just a warning - the rest of the modules are fine here.
This microservice uses Postgres and RabbitMQ, so I installed them (along with Erlang) too. The only difference compared to the OSX brew (a package manager, similar to apt, Chocolatey or many others) and rocket (a service manager) setup is that I had to manually enable the web admin on port 15672.
On the database part, I added my default user and created a database, but all of that could be done from the PgAdmin client effortlessly.
Step 6: Handling Environment Variables
Usually, Node.js projects are highly dependent on environment variables.
As you can see in the screenshot of my project, the IS_INTERACTIVE is an env var, which is very easy to define on Linux and OSX, but works a bit differently on Windows.
In the scripts section of the package.json you can use locally installed node modules. I suggest to avoid installing packages globally with
Also, I don't recommend adding env vars directly to the scripts section on Windows (or rather in a cross-platform team), but we have other options.
Npm passes these commands directly to the OS, in this case to the NT command interpreter (cmd.exe). The quickest fix is to copy the script line into our bash window and run it there, but of course, this will not work as a long-term solution. The newly announced bash shell support in Windows(in beta stage right now) will probably solve this issue.
The cleanest solution is to use one command per script line (as you can see, our
npm run lint command will work just fine).
Don’t use bash scripts, cmd can’t handle them. Cmd.exe supports &&, so two or three commands may be fine, but don't write a full shell script as a one liner (especially not with bash language features).
This is okay for support scripts, but to run our application, we will need lots of env vars.
At RisingStack, we use nodemon during development (some may use pm2 though). Nodemon is a file watcher and parses the nodemon.json file upon start, where one can define env vars.
I usually put nodemon. in my .gitignore_global file* (in the home dir, do not forget to initialize it with
git config --global core.excludesfile ~/.gitignore_global), this way I can have multiple nodemon json templates in my project.
While it’s not an elegant solution, I usually install nodemon globally. Sometimes it's easier just to launch it manually during development, not via the appropriate run script.
With the above json I can now start up my microservice, which will look like this:
Of course, nodemon may not be the best solution for just running scripts since I don't want to watch for file changes. For those cases, I usually convert my nodemon.json to a nodemon.sh, where I export each and every env var. Beware: You can call it anything you like, just do not forget to add it to the ignore file - pushing this file accidentally into a repo can give you a real headache:
export NODE_ENV="development" export PORT=3060 export AMQP_URI="amqp://localhost:5672/" export EMAIL_SENDER_NAME="Developer" #etc.
After this, I can source it on the command line (source nodemon.dev.sh) - this is for the MinGW bash we are using, but it would be easy to convert it to a traditional bat file. Since our DB setup needs a couple of env vars and I don't want to watch it, this is the quick and dirty way I run it locally. On a cloud provider, I would set up the env vars properly.
That's it, the project works, just like on OSX or Linux.
This covers our short Node.js on Windows 10 tutorial. Some of the modules in npm may not support Windows, but things are getting better. Windows has some nice and friendly GUI tools, and Visual Studio can be a powerful asset. If your team is willing to tolerate the extra overhead, it may be a viable option.
Please, share your questions and feedbacks in the comment section.