The Node.js 8.x Maintenance LTS cycle will expire on December 31, 2019 – which means that Node 8 won’t get any more updates, bug fixes or security patches. In this article, we’ll discuss how and why you should move to newer, feature-packed, still supported versions (like Node 12 – check out the new features here).
We’re also going to pinpoint issues you might face during the migration, and potential steps you can take to ensure that everything goes well.
TLDR: The Node.js Release Cycle
If you’d like to bury yourself in the Node Release cycle, you can visit https://github.com/nodejs/Release, or you can read our super-short summary below.
Let’s start with understanding the vital terminology first:
- Current version: The most recent release line, supported.
- LTS: A long-term supported version of Node.
- Active LTS: Actively maintained release, gets new features, bug fixes, improvements.
- Maintenance LTS: Only critical bug fixes and security fixes.
Once a release moves into Maintenance mode, only critical bugs, critical security fixes, documentation updates, and updates to ensure consistency and usability of the N-API across LTS releases will be permitted. Unless a change is urgent it will be planned into a release once per quarter. Such releases will only be made when necessary. – straight from the Node.js Release Docs.
Node 8’s End of Life is December 31, 2019. This means no more updates.
Take a look at this graph. It might help you to understand how the cycle works:
New even-numbered versions (e.g. v6, v8, v10, etc) are cut in April, while odd-numbered versions (e.g. v5, v7, v9) are cut in October.
When a new odd-release is cut, the previous even-numbered version transitions to LTS. Every LTS version is actively maintained for 18 months. Then, the LTS version transitions into “maintenance” mode for 12 additional months.
Okay, enough about the release cycle – let’s see how you MUST update Node.js
How to and why update your Node version?
New Node versions come with several bug and security fixes and new features as well. However, the transition from Node 8 to 10 brings a new change. Node not only depends on V8, libuv, and the Node core written in C++, but other projects as well, such as OpenSSL. This time, the maintenance window is aligned with the End Of Life of OpenSSL 1.0.2 and the introduction of OpenSSL 1.1.1 in Node 10+. This brings the possibility to support TLS 1.3 and FIPS.
Your dependencies may make updating Node a bit more difficult.
Before Node 8, upgrading was a lot more pain, as ES6 feature coverage raised dramatically between Node 6.0 and 8.0. (The majority of the changes came between Node 6.0 and 6.5 but it is safe to assume that most people reading this do not update their Node version that often.)
Adopting these new ES6 features required a lot of code change when we had to update from Node 6 to Node 8. This can be still true with Node 8, if you use native dependencies that rely on the V8 / NAN.
While Node 8 introduced the new N-API as an experimental feature, it has moved to stable with Node 10. The N-API provides an extra abstraction layer over V8 and NAN, making it possible to handle changes to them at a higher level, resulting in a more stable API surface.
The problem is that those versions of your dependencies that worked fine with Node 8 might not be compatible with the V8 / NAN version in later @nodejs versions.
Here’s a tale to illustrate this issue:
Let’s say you used a package called
awesomeNativeDependecy@1.15.2. It hooked straight into the V8 or NAN API to do its job.
Even while Node 8 was the latest stable version out, the developers of
awesomeNativeDependency came out with version
2.0.0 which introduced breaking changes to the functionality of the package.
Some of the native API endpoints changed by the time Node 10 came out, thus the developers of
awesomeNativeDependecy decided to only support
v2.x.x of their package, so they release
awesomeNativeDependecy@2.0.1. This new release is compatible with the native V8 or NAN API changes. Thus, if you wish to update your Node version to 10 or above, you need to use
This can result in you needing to rewrite the majority of your app’s code where you rely on
This is just one of the many scenarios that can lead to problems when trying to update your Node version past 8.
Even though the surface of Node.js is mostly backward compatible, your dependencies might not work well with older versions, so if you haven’t done so, be prepared for the change.
How not to break your Node app in Production
To make sure you don’t break your production app follow these steps to upgrade your Node version:
- Have a code base with good test coverage.
- Try to update your Node.js version locally.
- Run the tests
- Hope all of them pass
- If they do, change your Node version on your staging environment
- If all went well so far, upgrade your Node version on production
The easiest way to handle changes to your Node version is using nvm.
If you installed Node from source or from a package manager, make sure that when you run
which node, you get
$HOME/.nvm/versions/node/v$VERSION/bin/node and not in eg.
In case it’s not right, make sure that in your
$HOME/.nvm/versions/node/v$VERSION/bin/ comes later than wherever
which node points to.
This way, you can easily install and switch between different Node versions to go back and forth and see what breaks your tests.
After switching your node versions, make sure you reinstall your dependencies running a clean install with
npm run ci. This command will delete your current
node_modules folder and install your dependencies completely anew, making sure you’ll get the same error message you would get running
npm i on the freshly cloned repo, just as in your CI/CD pipeline.
Start upgrading Node.js 8 now!
If you didn’t update from Node 8 yet, it is high time to get started.
According to the current plan, @nodejs 8 will not get critical bug and security fixes starting from 2020 which can leave you exposed to otherwise avoidable threats.
While there is a pretty good chance that in your case it will be hassle free, it is definitely not guaranteed, and if your run into trouble, you might need to rewrite large chunks of your codebase, so better get started sooner than later.
In case you run into any trouble while upgrading your Node services, feel free to reach out to RisingStack at
email@example.com, or take a look at our Node.js Support Services.
We’ve been building products with Node.js in the past 5 years, and have the necessary experience to confidently guide you through the process.