It’s that time of year again where the Node.js community releases a new major release - Node.js 18. Following the well defined release process, this version will be promoted to long-term support (LTS) in October 2022. Before then, we need the greater ecosystem to try it out and give the community feedback. This will allow us to address any issues in advance and make sure both the release, the ecosystem, and our customers are ready when it’s promoted.
If you follow Red Hat’s work in the Node.js project, or have been following our regular updates you’ll see that our strategy is to focus our community work on aspects we believe are important to our customers, including:
- Stable and predictable releases
- Platform support
- Security
- Diagnostics
- Performance
- Code quality and safety net
- Key features
Those aspects,along with working with our customers and internal teams and sharing our experience in the Node.js reference architecture, keeps us pretty busy.
For the Node.js 18 release I’ll highlight some of the new features and ongoing work in the 18 timeframe and where our team’s been involved.Interesting new features include:
- Experimental Fetch
- Test Runner
- ECMAScript modules improvements
- Improved support for AbortController and AbortSignal
- Updated Platform Support
- V8 Version 10.1
- OPENSSL 3 Support
- Default DNS resolution
As you can see from the list, there is lots going on, with new experimental features like Fetch and Test Runner support and ongoing progress on some of the larger efforts like support for ECMAScript modules. Add to this updated platform support, a new version of V8 and updated cryptographic support, which are a common feature of most releases and we can see that Node.js development is moving ahead at a good pace.
The use of Node.js also continues to grow with almost 2 billion downloads of Node.js binaries and containers that we know about in the last year (based on our informal count using the Node.js download data and Docker hub pulls). In the context of Red Hat customers, we see continued growth in the downloads of Red Hat Node.js containers with a growth of almost 92% last year.
New features
Experimental Fetch
Soon after the Next-10 mini-summit on Modern HTTP and Documentation, an experimental implementation of the WHATWG Fetch was added. In the summit it was agreed that we needed a high level and a low level API and that Fetch was the right answer for the high level API. Making a request is as simple as:
const resp = await fetch(url)
You can read more about the people who contributed to make this happen in the community blog post. Many thanks for their hard work.
Experimental test runner
Node.js 18 includes an experimental test runner. It’s not intended to replace full featured alternatives like Jest or Mocha, but does offer a quick and easy way to run a test suite without any additional dependencies. It provides TAP output which is widely used and makes it easy to consume the output. You can read more about it in the community blog post and the Node.js API docs.
ECMAScript modules improvements
Since the introduction of ECMAScript module support, Node.js has continued to work on improvements. Some interesting additions since Node.js 17 include:
- JSON Import Assertions in line with the TC39 proposal
- A command line flag is no longer needed to use esm json modules (although it is still experimental)
- Experimental support for HTTPS and HTTP impo1998e83983rts under the --experimental-network-imports flag.
Work on larger initiatives like loaders and diagnostic channel are also underway in order to help improve observability when using ECMAScript modules.
Improving support for AbortController and AbortSignal
While AbortController and AbortSignal are not new in Node.js 18, work continues to expand support in the Node.js codebase. By our count there were 11 SemVer minor PRs adding functionality related to AbortSignal.
As an example, with the newly added AbortSignal.timeout(), you can now easily abort an HTTP request when using fetch with
const resp =
await fetch('http://slowsite.com', {signal: AbortSignal.timeout(1000)});
You can check out the full list of commits in the release changelog.
Stream improvements
Since the release of Node.js 17, there were 6 SemVer minor and 11 SemVer minor changes. This includes adding a number of Experimental methods to Readable streams such as:
Platform support
As with most major releases, this release updates the minimum supported levels for platforms and tooling used to build Node.js. Node's building instructions document these new minimum levels. Of note, the minimum glibc level required on Linux has been increased. This was necessary because the Node.js project builds its release binaries on RHEL/Centos (now just RHEL) and RHEL/CENTOS 7 will go out of service before the end of community support for Node.js 18. Thanks to Red Hat’s Richard Lau who put in many hours getting new RHEL 8 machines across the supported platforms into the Node.js community CI system.
For those who use the Red Hat Node.js binaries or containers, this change will not affect you as Red Hat builds and makes available binaries that match Fedora and RHEL major versions through rpms and containers.
V8 JavaScript engine version 10.1
The V8 JavaScript engine is the runtime environment that executes JavaScript code. It's what lets JavaScript run across many platforms so developers don't need to worry about whether their code is running on Linux, Windows, macOS or whether the hardware underneath the OS is x64, Arm, or Power PC. However, V8 is written in C++ and requires the Node community to maintain and improve V8 for assorted operating system and hardware combinations.
Because of this, the Red Hat Node.js team gets a "sneak peek" at what is coming in new versions of the V8 JavaScript engine. As the platform owners for Power PC and s390 directories within V8, we are hard at work making commits every week to keep V8 running on these platforms. It’s great to see that work pay off as new features come to Node.js. For more info on all the new features, keep an eye out for the blog post for all of the V8 versions between 9.6 (the latest version in Node.js 17) and 10.1 in the V8 blog.
OPENSSL 3 support
Node.js 17 was the first version to use OpenSSL 3 instead of OpenSSL 1.1.1 but it’s worth revisiting as Node.js 18 will be the first major version promoted to LTS with OpenSSL3. Red Hat's Daniel Bevenius and Richard Lau worked diligently to get OpenSSL 3 integrated into the Node.js code base. There are still a few rough edges but we hope that these can be ironed out before Node.js 18 gets promoted to LTS.
While the OpenSSL 3 APIs aim to be compatible with the previous OpenSSL version, there will be some impact on users due to the switch to OpenSSL 3 as each new version of OpenSSL tightens the allowable key sizes and algorithms that are available. If you are still using small keys or older algorithms you should plan time to understand how you might be affected. More information is available in the OpenSSL3 blog post.
Default DNS resolution
This change was also in Node.js 17 but is also worth noting as Node.js 18 will be the first version that will be promoted to LTS and may be the first time our customers run into it.
For dns lookups, Node.js no longer prefers IPv4 over IPV6. Instead, it will now respect the order that is returned based on the dns entries. For properly configured hosts this should not make a difference but if you have a partially or incorrectly configured IPv6 stack on your hosts you might start seeing problems that were hidden before. The command line option --dns-result-order=ipv4first can be used to revert to the old behavior if necessary.
Looking to the future
While a major release is a good time to look at what’s been accomplished, it’s also important to think about the future. The project has been doing this in the Next-10 effort and as part of that has defined the top 10 priorities:
- Modern HTTP
- Suitable types for end-users
- Documentation
- WebAssembly
- Support for features from latest ECMAScript spec
- Observability
- Permissions/policies/security model
- Better multithreaded support
- Single Executable Applications
Our team has helped the community host a number of mini-summit’s have been held to discuss what’s needed and identify next steps. Those summits have been a great way to make progress (fetch was landed in the project soon after the one on Modern HTTP) and we plan to have the next one at the Node.js collaborator summit at the upcoming OpenJS World conference. We hope to see you there or in the regular Next-10 meetings which can be found on the Node.js Project Calendar.
A big thank you
We’d like to thank all of the people who contribute to Node.js releases, including Red Hat's Bethany Griggs, on the Node.js releaser team, who created and coordinated the Node.js 18 release. The community has a large cast of contributors working across the Node.js project and each release is the result of all of their hard work.
As a side note, I’d also like to thank the companies/individuals who have stepped up to help with security releases as security release stewards or as part of the security triage team, along with all of those who make security releases happen. The major releases are the big splash, but security releases are just as important. I’d like to see more companies committing to help with security triage, security stewardship as well as fixing vulnerabilities.
Wrapping up
You can read about all the new features and changes from the community post here. To learn more about the Node.js community and to learn how you can contribute, check out the project repository and website. If you want to read more about what Red Hat is up to on the Node.js front, head to the Node.js developers page here. Finally, if you’re a Red Hat customer, visit the customer portal for more information.
저자 소개
Michael Dawson is an active contributor to the Node.js project and chair of the Node.js Technical Steering Committee (TSC). He contributes to a broad range of community efforts including platform support, build infrastructure, N-API, Release, as well as tools to help the community achieve quality with speed (e.g., ci jobs, benchmarking and code coverage reporting). As the Node.js lead for Red Hat and IBM, he works with Red Hat and IBM's internal teams to plan and facilitate their contributions to Node.js and v8 within the Node and Google communities. Dawson's past experience includes building IBM's Java runtime, building and operating client facing e-commerce applications, building PKI and symmetric based crypto solutions as well as a number of varied consulting engagements. In his spare time, he uses Node.js to automate his home and life for fun.
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.