This post is just one part in my 10-part email course Understanding the SharePoint Framework Development Toolchain which you can subscribe to and get delivered straight to your inbox.
You’ve made it… we’re now half way complete with the course! The best is ahead of you now… because while in day 5’s installment I covered what you needed to know vs. what you could know, now we are going to dig in and look at each component in the dev toolchain.
Today’s entry into my ten-day series is to look at Node.js and NPM. They are usually grouped together, and while I am doing that here in this installment, I personally see them as two very different things.
In the context of SharePoint Framework development, you should also treat them as different things because frankly, you don’t need to focus much at all on Node.js; just install it and move on. NPM is where you need to make sure that you are familiar with the commands including how to query, manage and upgrade new versions.
But there is something about Node.js you should be familiar with. While not required, you should consider using a node version manager, or the node version manager: NVM. It’s for MacOS, but there is a popular Windows port for it.
There are two main distributions of Node.js. The long-term support or LTS version is a version that has strict requirements for new features and updates. This is the version that many enterprises use because it’s not always changing and improving. It is also the version that Microsoft recommends for development with the SharePoint framework.
The other is what they call the current version. This has the latest features added to Node.js. Eventually, these features will make it into the LTS version, but in current they are less mature.
Personally, I use the current version, but in this course, we will follow Microsoft’s guidelines and use LTS.
Because most of the tools that we will use in the SharePoint development toolchain are built on Node.ja and require it. This gives us the cross-platform aspect of SharePoint framework development.
So what is NPM? NPM is the package manager for Node.js… get it… NPM? NPM is a node.js based tool that you use to acquire and manage packages within your projects. Some Node.js tools are also distributed using NPM. For instance, when you want to install a new version of the TypeScript compiler, you will run...
NPM install -g typescript
This tells NPM to install the package TypeScript globally. When you install something globally, it’s available anywhere in your environment. If you leave off that
-g it is installed locally in the current working directory.
A special note, make sure you are using NPM version 5 or higher. The reason for this is prior to version 5 (actually prior to version 3), when NPM downloaded a package, it then downloaded dependent packages into the folder of that package and repeated this process until it got everything. This created a massive package tree dependency and caused issues on Windows machines that have a history of issues with long file paths. NPM version 3 flatted this and kept everything in a single folder.
There are two ways you can get Node.js installed on your environment:
The first option is to head to the Node.js website, download an installer for the latest LTS version for your platform and follow the instructions.
This works, but you will find at times you have to work with Node.js as an admin, either within an administrative command prompt in Windows or by prefixing any Node based commands with
sudo on MacOS or Linux.
The other limitation of this approach is you can only have one version of Node.js & NPM installed at any time on your developer environment. Generally, that is not a big deal, it is just annoying at times.
The other option that I prefer is to use the Node.js version manager or NVM. Once installed, this helps you acquire different versions of node and switch between them.
Each Node.js install you get has it’s own global package installation folder so you can have different globally installed versions between node runtime installs.
It also avoids admin command prompts because it installs the node runtime within your profile. Since you always have admin rights over your profile, you are effectively always running as admin.
Personally, I like managing my Node.js installs using NVM because it lets me use the latest features but also get the flexibility of jumping between versions and trying new things out without impacting my current stable setup.
There is a version of NVM for both MacOS and Windows depending on your platform of choice.
Installing NVM and Node.js is very straightforward using the links I just provided. Personally, I’m a huge fan of NVM and use the versions listed above in both my MacOS laptop and Windows laptop.
NPM was the first package manager used to pull packages down from the NPM package registry at https://www.npmjs.org. This registry is the primary registry all Node.js projects and most client-side packages are pulled from. It’s replaced other registries such as Bower.
NPM maintained a hold on the package management space for a while, leaving developers to address its shortcomings around speed, consistency and version locking. Since competing package managers were introduced, specifically Yarn, NPM has stepped up its game and is on par for the most part with the others out there.
Yarn was created as a collaboration between Facebook and Google to address the shortcomings of NPM. The two biggest things it added was the concept of a lockfile and package cache.
The package cache helped eliminate the issue where each time you installed packages in a new project, instead of pulling a new copy from the NPM registry, Yarn would first check to see if you had already downloaded it in the past. If you had, it would skip the download process and instead just copy the package from the local cache into your project folder.
The lockfile would ensure that each time packages were installed with yarn, it the same version you got last time would be downloaded. Before this concept was introduced, if you ran installed packages on a Monday with NPM, and someone installed them on the same project on Wednesday, there was no guarantee you would get the same versions of the packages because someone may have shipped an update between the two days.
In the early days of SPFx, this happened a few times and even bit me one day: Troubleshooting and Fixing the “Out of the Blue, My SharePoint Framework Projects Won’t Build!”
This is the newest one on the scene. It does everything the other two generators do in the sense of lockfiles and a package cache. However, it has one different characteristic…
Instead of copying the packages from the cache to the project, it creates a hard link from the project’s node_modules folder to the folder in the package cache. This means your project folders are much smaller!
I would encourage you to consider the options and decide which one makes the most sense for you. I've written more about the three and provided a comparison in a blog post if you want to learn a bit more: NPM, Yarn and PNPM: Which Package Manager Should You Use for SharePoint Framework Projects?
That’s it for today’s installment. Tomorrow I’ll tackle the project creator: Yeoman.
Today's installment is actually from one of the lessons in the Mastering the SharePoint Framework - Starter Bundle course. This is a free resource you can subscribe to today, or you check out a preview of the course by watching the lesson associated with today's email course installment: