Node.js version 8 was just released and I thought I’d take you through some of the highlights.
In October this year Node.js version 8 will become the third LTS release since the move to the Node.js foundation. Having been involved in the early planning and discussions around LTS releases and lifespans, it is nice to see how well they have worked out. With 4, 6, and 8 rolling out at a regular cadence, things seem to be well on track for predictable releases both in terms of schedule and stability. You can find the latest LTS schedule here.
As with any current release, Node.js version 8 supports Linux on P, Linux on Z, and AIX. Make sure to check out the supported platform list in: BUILDING.md as some of the minimum OS levels have been updated.
Between now and October we don’t recommend version 8 for production, but it is a good time to try it out and report any issues so that they can be addressed before version 8 enters LTS.
Version 8 is business as usual with both incremental updates, updates to v8, and some key new features in Node.js itself. Some of the headline changes include:
If/when the update happens it will likely have an effect on the overall performance characteristics of Node.js. I’ve recently added version 8 to the nightly benchmark runs here so we be able to see any changes on our nightly benchmarks. A one-off run of Node.js with V8 5.9 as a comparison to the current Node.js version 8 showed some performance improvements. There is also ongoing community work to assess the impact of ignition+turbofan on the core micro-benchmarks. You can read about that work here.
Version 8 includes npm@5 hot off the presses. It has a number of new features and changes you can read about here.
I’ve been involved in the development of this API since the beginning, and it good to see it going out in this release. A more in depth introduction is covered in this blog that I co-authored: https://medium.com/@nodejs/n-api-next-generation-node-js-apis-for-native-modules-169af5235b06.
If you just want to dive into the details, the documentation is available here.
Debugger protocol/CLI debugger/Chrome developer tools
The previous debug protocol has been dropped with the move up to V8 5.8, replaced by a new protocol. To support this new protocol an updated command line interface (node-inspect) has been adopted by Node.js. Updated documentation is provided here. Also cool is that the chrome developer tools now have a dedicated page for connecting to Node.js through this protocol. You can access this page with about:inspect.
This is an easy and fast way to start debugging your Node.js processes.
Support for the WhatWG URL standard was added as an experimental feature in version 7 as an alternative to the existing url.parse() API. In version 8 it graduates out of experimental as a supported API. This provides standardized URL parsing to Node.js. You can read more about it here.
util.promisify was added in version 8 as a utility to make it easier and more efficient to use promises with existing Node.js APIs. It takes a function following the common Node.js callback style and returns a version that returns a promise. If you are a user of promises you should read about it here.
A new tracing feature was added which provides a way to centralize tracing information generated by Node core, v8 and user code. Right now most of the available events are generated by v8, but we hope to see the adoption/generation of trace events accelerate in future versions. You can read more about it here.
Version 8 includes an updated AsyncHooks API that will allow better instrumentation by Application Performance Management (APM) vendors, improving the data that can be provided as well as stability of the APM implementations across versions. The API allows callbacks to be registered which track the lifetime of asynchronous resources within a Node.js application. Look for the “Async Hooks” section (coming soon) in the Node.js API documentation.
Less exciting but just important is the ongoing work to improve the existing core runtime. This includes bug fixes, improvements to documentation and tests, along with some cleanup and tightening of the API contract. Ongoing work on this front is a sign of a vibrant and active project.
Version 8 continues the tradition of recent releases by making good progress on the test and documentation front. Of the total number of changes between version 6 and 8, roughly 1/3 of the changes fall into these categories:
|TYPE||v7 -> v8||v6 -> v8|
While the total number of changes is down slightly by comparison with the version 4 to version 6 transition (1613 versus 1792), it is in the same ballpark with a few less SEMVER-MINOR commits and more SEMVER-MAJOR commits. The major difference being less doc/test commits (~179 less). The changes as we move to version 8 include:
|TYPE||v7 -> v8||v6 -> v8|
Node.js uses SemVer to categorize changes. If you need a refresher on SemVer and the differences between major, minor and patch you can find it here: http://semver.org/.
While 1613 changes may seem like a lot, the transition from version 4 to version 6 was relatively smooth and we believe that it is likely that the same will apply to version 8.
When looking at the number of SEMVER-MAJOR changes, it is due to to the community being careful and marking commits as SEMVER-MAJOR that are potentially breaking even when we don’t believe most users will be affected by them. Some common examples are changes to error checking/handling and the contents of error messages. A concrete example is the push to add error ids to errors in order to make it easier/safer to translate and improve errors messages in the future: issue 11273.
A good way to start off to see if you think any of the changes will affect existing applications is to review the “Notable” changes listed in the changelog. That list highlights the changes the community feels are most likely to be noticed. In addition, we’ll be following up this blog with a more in depth dive into some of the SEMVER-MAJOR changes.
I hope you are as excited about Node.js version 8 as I am. It brings all these exciting changes, along with incremental improvements and bug fixes which should make it one of the best releases so far. It’s time to start planning to test over the next few months so that you are ready to adopt soon after it becomes LTS in October.