A Node.js 9.0.0 Release Summary

October 31, 2017 - by Colin J. Ihrig

October means two things: pumpkin spice everything and Node.js release line updates. The Node.js project makes various releases year round which include minor improvements, bug fixes, and new features. Twice per year, in April and October, the project cuts a new major release. Each major release is the culmination of six months of code changes, some of which may break compatibility with previous versions. This release process is captured in the following image.

Node.js Release Schedule

October is particularly exciting because it's the one time per year that a major release line enters Long Term Support (LTS). You can read more about the recent Node.js 8 LTS transition in Wyatt Preul's blog post.

What to expect

Before looking at Node.js 9.0.0 in detail, it's important to set some expectations:

Major releases of Node.js are generally uninteresting.

If major releases contain all of the breaking changes, how can they possibly be boring? The answer to this question has several components.

  • New APIs, new language features, and V8 updates typically generate the most excitement among developers. With the exception of backward incompatible V8 updates, these are usually classified as semver minor changes, or feature additions. Since semver minor releases are made on an ongoing basis, the "exciting" changes don't need to wait for a new major release line.

  • The project tries really hard not to break existing code. When breaking changes are made, they are typically not very drastic. Instead, they focus on small, incremental improvements that just happen to be backward incompatible. The bulk of these changes involve the deprecation or removal of legacy APIs. Furthermore, before an API is removed, the core team attempts to gauge ecosystem usage and impact. If a particular API is widely used, it may not be removed. An example of this is the Buffer constructor. Another common breaking change is updating the wording of an error message, as there are modules that parse error message strings. Node.js is currently moving towards an error code system, which will make this type of breaking change a thing of the past.

Release breakdown

This section lists some of the notable changes in Node.js 9.0.0. Some of the items in this list arrived very recently in Node 8, but warrant mentioning here.

  • Several of Node's biggest dependencies have been updated. This includes V8 6.2, libuv 1.15.0, and c-ares 1.13.0. These specific dependencies represent the JavaScript engine, asynchronous I/O library, and DNS library used by Node.js.
  • N-API and HTTP2 are both available for use without a command line flag. These features, along with Async Hooks represent exciting new features that you can experiment with today, although they are all technically still listed as experimental.
  • The Node.js core codebase is slowly migrating to a new error system. The goal of this migration is to associate a unique code with all errors thrown by Node.js. This will allow error messages to be changed without being considered breaking. It will also make user code more robust by not relying on error messages.
  • The http module will now return a 400 status code when an incoming request cannot be parsed successfully. In the past, Node.js would simply hang up the socket, causing other servers, such as nginx, to assume the Node.js server was down.
  • The assert module's methods can now throw any type of error (RangeError, SyntaxError, etc.). In previous versions of Node.js, these methods could only throw assertion errors.
  • Timers now emit a warning if the delay overflows. Node.js represents timer delays as a 32-bit signed integer. On overflow, a timeout of one millisecond is used. Previous versions of Node.js did not provide any indication that an overflow occurred.
  • Both the API documentation and test suite receive a constant stream of improvements. While these changes are not directly reflected in the node binary, they are critical to the success of Node.js, and make up the bulk of every release. For those reasons, they are included in this list. And, in case you were curious, Node.js core currently has approximately 94% and 91% code coverage in the JavaScript and C++ layers, respectively.

Who should run Node.js 9.0.0

Now that it is available, the 9.x release line will receive all non-breaking changes that land in the master branch until Node.js 10.0.0 is released in April. The Node.js 9.x line will never enter LTS and will reach end-of-life (EOL) shortly after the Node.js 10 release. Additionally, while it is expected that no breaking changes will be introduced in Node.js 9.x, history has shown that there will likely be some accidental breakage. As a non-LTS release, Node.js 9.x does not come with the same stability guarantees as an LTS release.

If you (or your company) can safely exist closer to the bleeding edge, tolerate possible unexpected breakage, and can easily switch between Node.js versions, then Node.js 9.0.0 is a viable option for you.

If you are running Node.js in mission-critical areas, require the utmost level of stability, or cannot easily move between Node.js versions, then Node.js 9.0.0 is not a viable option for you. If you fall into this category, you absolutely should be running an LTS release.

Conclusion

This post has explored the Node.js 9.0.0 release at a high level. It also detailed who is a prospective user of Node.js 9.0.0, and who should be using LTS instead. If anything in this post is unclear, please reach out. Joyent offers comprehensive Node.js support and would love to help you succeed.