This blog was written by Bethany Griggs and Michael Dawson, with additional contributions from the Node.js Release Team and Technical Steering committee.
We are excited to announce Node.js 12 today. Highlighted updates and features include faster startup and better default heap limits, updates to V8, TLS, llhttp, new features including diagnostic report, bundled heap dump capability and updates to Worker Threads, N-API and ES6 module support and more. The Node.js 12 release replaces version 11 in our current release line. The Node.js release line will become a Node.js Long Term Support (LTS) release in Oct 2019 (more details on LTS strategy here).
V8 Gets an Upgrade: V8 update to V8 7.4
As always a new version of the V8 JavaScript engine brings performance tweaks and improvements as well as keeping Node.js up with the ongoing improvements in the language and runtime. Highlights include:
- Async stack traces: https://v8.dev/blog/v8-release-72#async-stack-traces
- Faster calls with arguments mismatch: https://v8.dev/blog/v8-release-74#faster-calls-with-arguments-mismatch
- Faster await: https://v8.dev/blog/v8-release-73#faster-await
- Faster javascript parsing: https://v8.dev/blog/v8-release-72#javascript-parsing
Read more about V8 at their official blog.
Hello TLS 1.3
Node.js 12 is introducing TLS1.3 support and making it the default max protocol, while also supporting CLI/NODE_OPTIONS switches to disable it if necessary.
TLS1.3 is a major update to the TLS protocol, with many security enhancements and should be used over TLS1.2 whenever possible.
TLS1.3 is different enough that even though the OpenSSL APIs are technically API/ABI compatible when TLS1.3 is negotiated, changes in the timing of protocol records and of callbacks broke assumptions hard-coded into the ‘tls’ module. This change introduces no API incompatibilities when TLS1.2 is negotiated. It is the intention that it be backported to current and LTS release lines with the default maximum TLS protocol reset to ‘TLSv1.2’. This will allow users of those lines to explicitly enable TLS1.3 if they want. If you want to read more you can check out these related articles:https://developer.ibm.com/blogs/openssl-111-has-landed-in-nodejs-master-and-why-its-important-for-nodejs-lts-releases/, https://developer.ibm.com/blogs/tls13-is-coming-to-nodejs/
Properly configure default heap limits
This update will configure the JavaScript heap size based on available memory instead of using defaults that were set by V8 for use with browsers. In previous releases, unless configured, V8 defaulted to limiting the max heap size to 700 MB or 1400MB on 32 and 64-bit platforms respectively. Configuring the heap size based on available memory ensures that Node.js does not try to use more memory than is available and terminating when its memory is exhausted.
This is particularly useful when processing large data-sets. As before, it will still be possible to set — max-old-space-size to use a different limit if the default is not appropriate for your application.
Switch default http parser to llhttp
Node.js 12 will also switch the default parser to llhttp. This will be beneficial in that it will make testing and comparing the new llhttp-based implementation easier. First introduced as llhttp experimental in v11.2.0, llhttp will be taken out of experimental in this release.
Making Native Modules Easier — progress continues
Node.js 12 continues the trend of making building and supporting native modules easier. Changes include better support for native modules in combination with Worker threads, as well as N-API (https://nodejs.org/api/n-api.html#n_api_n_api) version 4 (which has also been backported to 8.x and 10.x) which makes it easier to use your own threads for native asynchronous functions. You can read more about this and how you can leverage it in your modules in this great article here: https://medium.com/the-node-js-collection/new-features-bring-native-add-ons-close-to-being-on-par-with-js-modules-cd4f9b8e4b4
Worker Threads
Worker Threads (https://nodejs.org/api/worker_threads.html), while not new in this release, are still seeing progress. The use of Workers Threads no longer requires the use of a flag and they are progressing well towards moving out of experimental. While Node.js already performs well with the single-threaded event loop, there are some use-cases where additional threads can be leveraged for better results. We’d like you to try them out and let us know what use cases you have where they are helpful. For a quick introduction check out this great article: https://medium.com/@Trott/using-worker-threads-in-node-js-80494136dbb6.
Diagnostic Reports
Node.js 12 brings with it a new experimental feature “Diagnostic report.” This allows you to generate a report on demand or when certain events occur. This report contains information that can be useful to help diagnose problems in production including crashes, slow performance, memory leaks, high CPU usage, unexpected errors and more. You can read more about it in this great article: https://medium.com/the-node-js-collection/easily-identify-problems-in-node-js-applications-with-diagnostic-report-dc82370d8029.
Heap Dumps
If you ever needed to generate heap dumps in order to investigate memory issues but were slowed down by having to install a new module into production, the good news is that Node.js 12 brings integrated heap dump capability out of the box. You can check out the documentation in https://github.com/nodejs/node/pull/27133 and https://github.com/nodejs/node/pull/26501 to learn more.
Startup Improvements
In Node.js 11 we shipped built-in code cache support in workers — when loading built-in libraries written in JavaScript, if the library was previously compiled on the main thread, the worker thread no longer needs to compile it from scratch but can reuse the v8 code cache generated by the main thread to speed up compilation. Similarly, the main thread can reuse the cache generated by workers. This gave a roughly 60% speedup for the startup of workers.
Now in Node.js 12 we generate the code cache for built-in libraries in advance at build time, and embed it in the binary, so in the final release, the main thread can use the code cache to start up the initial load of any built-in library written in JavaScript. This gives a ~30% speedup in startup time for the main thread.
ES6 Module Support
Node.js 12 brings an updated experimental version of support for ES6 modules. It is an important step toward a supported implementation and we’d like you to try it out and give us feedback. For more details check out this great blog post.
New compiler and platform minimums
Node.js and V8 continue to embrace newer C++ features and take advantage of newer compiler optimizations and security enhancements. With the release of Node.js 12, the codebase now requires a minimum of GCC 6 and glibc 2.17 on platforms other than macOS and Windows. Binaries released at Node.js org use this new toolchain minimum and therefore include new compile-time performance and security enhancements.
The increment in minimum compiler and libc requirements also increments minimums in supported platforms. Platforms using glibc (most platforms other than macOS and Windows) must now include a minimum version of 2.17. Common Linux platforms compatible with this version include Enterprise Linux 7 (RHEL and CentOS), Debian 8 and Ubuntu 14.04. Binaries available from nodejs.org will be compatible with these systems. Users needing to compile their own binaries on systems not natively supporting GCC 6 may need to use a custom toolchain. Even though Node.js 12.0.0 may compile with older compilers, expect the Node.js 12 codebase (including V8) to rapidly adopt C++ features supported by GCC 6 during the pre-LTS timeframe.
Windows minimums remain the same as Node.js 11, requiring at least Windows 7, 2008 R2 or 2012 R2 and a minimum compiler of Visual Studio 2017. macOS users needing to compile Node.js will require a minimum of Xcode 8 and Node.js binaries made available on nodejs.org will only support a minimum of macOS 10.10 “Yosemite”.
Further details are available in the Node.js BUILDING.md.
Thank you!
A big thank you to everyone who made this release come together, whether you submitted a pull request, helped with our benchmarking efforts, or you were in charge of one of the release versions. We’d also like to thank the Node.js Build Working Group for ensuring we have the infrastructure to create and test releases. The release manager for Node.js 12 is Bethany Griggs. For a full list of the release team members head here. You can read more about the complete list of features here.
If you are interested in contributing to Node.js, we welcome you. Learn more via our contributor guidelines.
