Skip to main content
Category

Node.js

Using AbortSignal in Node.js

By Blog, Node.js, tutorial

By: James Snell, originally published on Nearform July 22, 2021

Foreword by: David Mark Clements

Dave Clements is an open source advocate and is the tech lead and primary author of OpenJS Foundation Node.js training and certification programs. And a big thank you to Nearform and James Snell for allowing the OpenJS Foundation to repost this article.

Foreword

The OpenJS Node Application Developer certification is an evergreen program that stays up to date
with advancements in the JavaScript specification, Node.js core, industry trends, and best practices
not only to ensure that the examination and training stay relevant but also to help disseminate
important information for the Node & JavaScript community.

With that in mind, the following article by James Snell is republished with permission from
James and NearForm where the article was first published. We strongly recommend anyone thinking
of taking the JSNAD certification read this article and consider the implications. We hope you
enjoy it!

The AbortController and AbortSignal APIs are quickly becoming the standard mechanism for canceling asynchronous operations in the Node.js core API.

If you search how to use the Promise.race() API, you’ll come across quite a few variations of the following:

The intent here is straightforward: Start a potentially long-running task but trigger a timeout if that task takes too long to complete. This is generally a good idea, but there are quite a few problems with this common example.

First, although the promise returned by Promise.race() will be fulfilled as soon as the first of the given promises is settled, the other promises are not cancelled and will keep on running. Although the timeout timer did fire, the long-running task is never actually interrupted and stopped.

Second, what happens to the timeout promise if the long-running task completes before the timeout is triggered? The answer is simple: The timer keeps running, and the promise will end up rejecting, still with an unhandled rejection — unnecessarily risking performance issues and possible memory leaks in your application.

To correctly handle this pattern, we need a reliable mechanism for signalling across the two promises, canceling either the timer or the long-running task as appropriate and ensuring that once the timeout is triggered all resources are cleaned up as quickly as possible. Fortunately, Web Platform APIs provide a standard mechanism for this kind of signalling — the AbortController and AbortSignal APIs.

In Node.js, a better way if implementing a Promise.race-based timeout would be:

As with the previous example, two promises are created. However, when each completes, it uses the AbortController and AbortSignal APIs to explicitly signal to the other that it should stop. As long as the code in those is written to support the AbortSignal API, everything just works.

For instance, in the example we make use of the recently added awaitable timers API in Node.js. These are variants of the setTimeout() and setInterval() that return promises.

The awaitable timer API supports the ability to pass in an AbortSignal instance. When the AbortSignal is triggered, the timer is cleared and the promise immediately rejects with an AbortError.

Support for AbortController and AbortSignal is being rolled out across the Node.js core API and can now be found in most of the major subsystems. Before we explore where the API can be used, let’s find out a bit more about the API itself.

All about AbortController and AbortSignal

The AbortController interface is simple. It exposes just two important things — a signal property whose value is an AbortSignal and an abort() method that triggers that AbortSignal.

The AbortSignal itself is really nothing more than an EventTarget with a single type of event that it emits — the ‘abort’ event. One additional boolean aborted property is true if the AbortSignal has already been triggered:

The AbortSignal can only be triggered once.

Notice that when I added the event listener in the example above, I included the { once: true } option. This ensures that the event listener is removed from the AbortSignal as soon as the abort event is triggered, preventing a possible memory leak.

Note that it’s even possible to pass an AbortSignal onto the addEventListener() itself, causing the event listener to be removed if that AbortSignal is triggered.

This starts to get a bit complicated too, but it’s important for preventing memory leaks when coordinating the cancellation of multiple complex tasks. We’ll see an example of how this all comes together next.

Implementing API support for AbortSignal

The AbortController API is used to signal that an operation should be cancelled. The AbortSignal API is used to receive notification of those signals. They always come in pairs.

The idiomatic way of enabling a function (like the someLongRunningTask() function in our examples above) to support this pattern is to pass a reference to the AbortSignal in as part of an options object:

Within this function, you should immediately check to see if the signal has already been triggered and, if it has, immediately abort the operation.

Next, it’s important to set up the handling of the ‘abort’ event before starting to process the task:

Notice here that we are creating an additional AbortController instance whose signal is passed in with the event listener. After we’ve completed the asynchronous task, we trigger that AbortController to let the AbortSignal know that the event handler can be removed. We want to make sure that the listener is cleaned up even if the async task fails, so we wrap the call to taskDone.abort() in a finally block.

It is also important to check if the signal has been triggered between various async tasks the method may be performing. This is important to catch cases where the event may not yet have had an opportunity to be emitted but the operation should still be interrupted.

Using AbortController and AbortSignal

The AbortController and AbortSignal APIs are quickly becoming the standard mechanism for canceling asynchronous operations in the Node.js core API.
For example, as of node.js 15.3.0, it is possible to cancel an HTTP request using the API:

Consult the Node.js documentation for more details on exactly which APIs support AbortSignal. More are being added all the time and support may vary across different Node.js major versions.

Node.js 18 Released With Improved Security, Fetch API, and Next-10 Strategic Initiatives

By Blog, Node.js, Project Update

Node.js 18 is available now! It adds multiple key features of enterprise and small- to medium-sized enterprises including increased security support, the Fetch API, and it is part of delivering on the larger Next-10 strategic initiative within Node.js that is pushing forward key priorities including modernizing HTTP and keeping Node.js on the forefront of web development. 

As part of increased security support, Node.js has been announced as the first pilot open source community to be supported by OpenSSF’s Alpha-Omega Project. Alpha-Omega is committing $300k to bolster the Node.js security team and vulnerability remediation efforts through the rest of 2022, with a focus on supporting better open source security standards and practices.

“The Node.js team continues to do fantastic work. The open governance structure for Node.js has led to tangible improvements in security and forward-thinking planning, and the main features of Node.js 18 will be highly valuable to enterprises of all sizes,” said Robin Ginn, OpenJS Foundation executive director. “Whether you’re a new user or already have Node.js broadly implemented, now’s a good time to install and test Node.js 18.”

Following its long-established release schedule, Node.js 18 is a Current release, which means it’s the right time for testing by enterprises, before being suitable for production usage when it is promoted to long-term support (LTS) in October 2022.

“The Node.js project contributors and collaborators continue to do an excellent job, and I want to thank them all. We continue to improve and grow, and I believe Node.js is a real open source success story,” said Bethany Griggs, Node.js Technical Steering Committee member, and Senior Software Engineer at Red Hat. “As always, current releases, like Node.js 18, are the perfect time to test in your own unique development environment. If you’re a Node.js user, please try out Node.js 18 and give us feedback. Your feedback directly contributes to our ability to move new features into stable releases more quickly.” 

For comprehensive information on specific Node.js features, see the Node.js team release announcement written by the Node.js project contributors: LINK

There are three key reasons to evaluate and upgrade to Node.js 18: Security, APIs, Future Planning.

Security

This is the first version that will be later promoted to LTS with OpenSSL 3.0. OpenSSL 3.0 is a major new stable version of the popular and widely used cryptography library. OpenSSL contains an open-source implementation of the SSL and TLS protocols, which provide the ability to secure communications across networks. Among other key features, OpenSSL 3.0 contains a FIPS Module that has been submitted for validation. The Federal Information Processing Standards (FIPS) are a set of requirements enforced by the US government which govern cryptographic usage in the public sector. This is a key step forward in the cryptographic support in Node.js.

The Node.js project follows a well planned security release process, with regular outbound communications and more. In the last year, Node.js has formalized rotations around security. The commitment to take slots in the security release steward rotation is made by companies in order to ensure individuals who act as security stewards have the support and recognition from their employer to be able to prioritize security releases. 

APIs

Node.js 18 is adding even tighter synergy between front-end and back-end APIs. One of the key premises of Node.js is that JavaScript skills can be applied to the back-end. With Node.js 18, Fetch is globally available by default. The Fetch API provides an interface for fetching resources including across networks. It will seem familiar to anyone who has used XMLHttpRequest, but the new API provides a more powerful and flexible feature set.

“Node.js 18 will enable the Fetch API as a default. It’s been available since Node.js 17, but this moves forward Node.js application development, and it’s exciting to be a part of the process of improving Node.js in key fundamental areas,” said Michaël Zasso, Scientific research software engineer and co-founder at Zakodium, member of the Node.js Technical Steering Committee. “I would like to thank multiple team members and contributors, and in particular I would like to thank users who push us and support us. Thank you!”

XMLHttpRequest has been used by web developers enabling ajax and a whole new kind of interactive exposure. However, it has been slowly succeeded by Fetch API. Fetch API is Promise based, providing a cleaner and more concise syntax.

Future Planning

The Next-10 effort has elevated technical priorities which have led to discussions around modernizing http. The purpose of the Next-10 project is to work collaboratively on the strategic directions for the next 10 years of Node.js. Fetch API is one direct result of this process. The full Next-10 repository is available here: https://github.com/nodejs/next-10 

Node.js Training and Certification

The OpenJS Node.js Services Developer (JSNSD) and OpenJS Node.js Application Developer (JSNAD) certifications are available now. Node.js training courses are available to help you prepare for the exams: Node.js Application Development (LFW211) and the Node.js Services Development (LFW212). Discounts are available to members!

OpenJS Resources

Click here to learn more about how you could be a part of the OpenJS Foundation, and view these additional resources:

About OpenJS Foundation

The OpenJS Foundation is committed to supporting the healthy growth of the JavaScript ecosystem and web technologies by providing a neutral organization to host and sustain projects and collaboratively fund activities for the benefit of the community at large. The OpenJS Foundation is currently home to 39 open source JavaScript projects, including Appium, Dojo, Electron, jQuery, Node.js, and webpack. It is supported by 30 corporate and end-user members, including GoDaddy, Google, IBM, Intel, Joyent, Microsoft, and Netflix. These members recognize the interconnected nature of the JavaScript ecosystem and the importance of providing a central home for projects which represent significant shared value. 

About Linux Foundation
Founded in 2000, the Linux Foundation is supported by more than 1000 members and is the world’s leading home for collaboration on open source software, open standards, and open hardware. Linux Foundation projects like Linux, Kubernetes, Node.js, and more are considered critical to developing the world’s most important infrastructure. Its development methodology leverages established best practices and addresses the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit their website.

Open Source Security Foundation (OpenSSF) Selects Node.js as Initial Project to Improve Supply Chain Security

By Announcement, Blog, Node.js, Uncategorized

From: Brian Behlendorf, OpenSSF Foundation, and Robin Bender Ginn, OpenJS Foundation

Today, we’re excited to announce that Node.js is the first open source community to be supported by OpenSSF’s Alpha-Omega Project. Alpha-Omega is committing $300k to bolster the Node.js security team and vulnerability remediation efforts through the rest of 2022, with a focus on supporting better open source security standards and practices.

The open source software project Node.js is everywhere, and people put a lot of trust into the products and services that are built with Node.js, from NASA to Netflix. But many community-led JavaScript projects lack the time, people, and expertise for comprehensive security measures. Few companies that depend on Node.js contribute back to the project. Our hope is this can inspire more organizations that depend upon Node.js to also participate in its security efforts.

This assistance will relieve the pressure on Node.js project maintainers who are strained by market demands for new features while striving for a stable and secure codebase. Specifically, this will bring in security engineering resources from NearForm and Trail of Bits to support the Node.js Technical Steering Committee, help triage reports, steward security releases, improve security broadly for Node.js, and encourage implementing best practices in JavaScript projects across the industry.

Node.js carries a high criticality score for its influence and importance based on parameters established by industry security experts at OpenSSF. Almost 98% of the world’s 1.9 billion websites use JavaScript, the top programming language according to research by RedMonk and GitHub. Node.js – server-side JavaScript – was downloaded over 2 billion times in 2021. It’s pervasive across the industry, used in a significant portion of modern applications.

Both of us (Robin and Brian) are excited about this collaboration and the prospect of setting an example for both the OpenSSF and OpenJS communities.

Node.js Trademarks Transferred to OpenJS Foundation

By Blog, Node.js

OpenJS Foundation had previously been granted free, perpetual license to use Node.js trademarks and logo for the past 6 years

SAN FRANCISCO – February 14, 2022 – The OpenJS Foundation, providing vendor-neutral support for sustained growth within the open source JavaScript community, is announcing acquisition of ownership of the Node.js logo trademarks. 

Effective immediately, the OpenJS Foundation will take on the ongoing management and maintenance of the Node.js trademarks. The ownership and stewardship of the Node.js trademarks has moved from Joyent to the OpenJS Foundation. The rules governing usage of the Node.js trademarks will now be consistent with all of the other OpenJS Foundation projects’ trademarks. For contributors, nothing will change. 

Node.js is an Impact Project hosted at the OpenJS Foundation. For the past six years, Joyent has granted the OpenJS Foundation (and the Node.js Foundation prior) a perpetual, free license to use the “Node.js” trademarks, including the Node.js hexagon graphic.

The Node.js Technical Steering Committee (TSC) responded to the news, “It’s great to see the Node.js trademarks move over to the OpenJS Foundation. It’s been a hope since the formation of the Foundation and we’re happy to see it become a reality. One of the advantages of Node.js being a project at the OpenJS Foundation is legal support including the management of things like trademarks to help protect the work of the broad range of collaborators.”

Trademarks are important to the protection and adoption of an open source project because they identify a specific source of the code. Our goal is to ensure that the OpenJS trademark policy is as flexible and easy to understand as legally possible, while assuring the quality of products or services using Node.js or other OpenJS projects’ brands

“The responsible stewardship of the Node.js project over the past decade has led to critical, widespread adoption. This stewardship and positive collaboration between Joyent and originally the Node.js Foundation, now the OpenJS Foundation, has helped overcome differences among the contributors and the code base,” said Robin Ginn, OpenJS Foundation Executive Director. “Joyent can confidently contribute its trademarks to the OpenJS Foundation as a place of stability and industry-wide collaboration.” 

“Joyent has long believed in the power of open source to create opportunities for developers and businesses, and it’s gratifying to see how Node.js underpins the economic growth for so many,” said Sung Whan Moon, President & COO, Joyent. “The OpenJS Foundation is the right place to house ownership of the Node.js trademarks. As Node.js moves into its second decade, having the trademarks in a neutral home, but with the ability to enact trademark restrictions if needed, fully ensures the integrity of the project.”

Node.js is a healthy community supported extensively by companies that have increased the scale and commercial adoption of this project, including Bloomberg, NASA, Netflix, and many more. Node.js just shipped Node.js 17 and moved Node.js 16 to Long Term Support (LTS).

“The OpenJS Foundation will make a good home for the Node.js trademarks. Joyent is a long-standing member of the OpenJS Foundation, and developers can continue to rely on Node.js and build high quality solutions and products,” said Sean Johnson, Head of Commercial Group, Joyent, and OpenJS Board Platinum Director. “The outlook for Node.js adoption is brighter than ever.”

“A big thank you to OpenJS Foundation member Joyent. They are an important community member of the Node.js ecosystem and have assisted in the stewardship of the Node.js trademarks for the past decade. This is a good progression forward, and bodes well for the next decade of Node.js development,” said Todd Moore, VP of Open Technology and Developer Advocacy at IBM, and OpenJS Foundation Board Chairperson. “The OpenJS Foundation is positioned well to pursue its mission of driving the broad adoption of JavaScript technologies and ongoing development of key Node.js solutions and related technologies.”

Work is well underway on the future of Node.js at the OpenJS Foundation, and Node.js continues to grow. The OpenJS Foundation staff and Cross Project Council (CPC) community technical leaders are working on security and diversity efforts and much more. The Node.js maintainers are working collaboratively on the strategic directions for Node.js over the coming decade. If you want to join this effort please see Node.js next-10 and join one of the projects teams or working groups.

OpenJS Resources

To learn more about how you could be a part of the OpenJS Foundation, click here.

About OpenJS Foundation

The OpenJS Foundation is committed to supporting the healthy growth of the JavaScript ecosystem and web technologies by providing a neutral organization to host and sustain projects, as well as collaboratively fund activities for the benefit of the community at large. The OpenJS Foundation is made up of 38 open source JavaScript projects including Appium, Dojo, jQuery, Node.js, and webpack and is supported by 30 corporate and end-user members, including GoDaddy, Google, IBM, Intel, Joyent, and Microsoft. These members recognize the interconnected nature of the JavaScript ecosystem and the importance of providing a central home for projects which represent significant shared value. 

About Linux Foundation

Founded in 2000, the Linux Foundation is supported by more than 1000 members and is the world’s leading home for collaboration on open source software, open standards, and open hardware. Linux Foundation projects like Linux, Kubernetes, Node.js and more are considered critical to the development of the world’s most important infrastructure. Its development methodology leverages established best practices and addresses the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit their website.

Media Contact

Jesse Casman

Story Changes Culture

jesse@storychangesculture.com

415-730-2793

Latest Node.js Savings End February 11, 2022

By Blog, Certification and Training, Node.js

It’s always a great time to invest in training or certification for you or your engineering team. The OpenJS Foundation, in partnership with the Linux Foundation, will be discounting all Node.js Certifications and Trainings up to 60% through Friday, February 11, 2022. Some of the world’s leading tech companies use the Node.js runtime in production and prefer to hire developers who are experienced with Node.js. The OpenJS Certification and Training program serves to help developers in their professional development goals.

Discounts Up to 60% with Code: NODE222 

OpenJS Node.js Services Developer Certification Exam (JSNSD) $375 $150

OpenJS Node.js Application Developer Certification Exam (JSNAD) $375 $150

Node.js Services Development Online Course + JSNSD Exam Bundle $575 $230

Node.js Application Development Online Course + JSNAD Exam Bundle $575 $230

POWER Bundle – JSNSD Course & Exam Bundle AND JSNAD Course and Exam Bundle $1150 $460

What’s included with certifications?

  • 12 month exam eligibility    
  • Free exam retake
  • Digital badge and PDF certificate upon passing

What’s included in online trainings?

  • Hands-on labs & assignments
  • Video content
  • 12 months of access to online courses
  • Discussion forums
  • Digital badge and PDF certificate upon completion

Certifications

Certifications are excellent ways to validate your own development skills to yourself, employers, and the world. 

OpenJS Node.js Application Developer (JSNAD)
The OpenJS Node.js Application Developer certification is ideal for the Node.js developer with at least two years of experience working with Node.js. For more information and how to enroll: https://training.linuxfoundation.org/certification/jsnad/

OpenJS Node.js Services Developer (JSNSD)
The OpenJS Node.js Services Developer certification is for the Node.js developer with at least two years of experience creating RESTful servers and services with Node.js. For more information and how to enroll: https://training.linuxfoundation.org/certification/jsnsd/

Training Offerings

Feel confident in taking your exams with the Node.js Training courses. These courses help prepare developers for the Node.js certification exams. 

Node.js Application Development (LFW211)
This course provides core skills for effectively harnessing a broad range of Node.js capabilities at depth, equipping you with rigorous skills and knowledge to build any kind of Node.js application or library. While by design the training content covers everything but HTTP and web frameworks, the crucial fundamentals presented prepares the student to work with web applications along with all types of Node.js applications.

Node.js Services Development (LFW212)
This course provides a deep dive into Node core HTTP clients and servers, web servers, RESTful services and web security essentials. With a major focus on Node.js services and security, this content is an essential counterpart to the Node.js Application Development (LFW211) course, and will prepare you for the OpenJS Node.js Services Developer (JSNSD) exam.

If you’d like to pursue Node.js Certifications and Trainings and this sounds like something you’d like to know more about, check out more information at this link.

Node.js in an Impact Project of the OpenJS Foundation.

Test your skills! How good are you with Node.js?

By Blog, Certification and Training, Node.js

Lock in Best Pricing of the Year Available for One Week Only! Steep Discounts on OpenJS Foundation Node.js Training & Certification for Cyber Monday

Want to know where you stand with Node.js? Having a vendor-neutral Node.js certification badge from the OpenJS Foundation on your profile is an easy way for peers and managers to know that your knowledge has been fully tested. 

Cyber Monday offers the best discounts of the year on OpenJS Foundation Node.js Training & Certification. Available for one week only!

Job openings are at record highs, and Node.js developers are in high demand. The 2021 Open Source Jobs Report found that 92% of hiring managers are unable to find enough talent to meet their organizations’ needs. If you know Node.js, you can stand out through the OpenJS Node.js Training and Certification. 

An important goal of the OpenJS Foundation is helping close the talent gap so the industry has the talent necessary to build their business, while also creating accessible pathways for anyone who wants to build their career with JavaScript and related technologies.

We are excited to offer our best pricing of the year on our Node.js training courses, certification exams, and bundled programs, for Cyber Monday. From now through December 6, 2021, all these fantastic offerings are available at significantly reduced cost. Through our partnership with the Linux Foundation, we’re providing vendor-neutral training directly from the experts helping build these projects.

This year’s Cyber Monday offers include:

PowerBundle (Save 65%. Use Code: CYBER21PB)

Pricing:  Pricing is $1150 $399

  • PowerBundle
    • Linux Foundation Node.js Application Development Training (LFW211) + 
    • OpenJS Foundation Node.js Application Development Certification Exam (JSNAD) + 
    • Linux Foundation Node.js Services Development Training (LFW212) + 
    • OpenJS Foundation Node.js Services Development Certification Exam (JSNSD)

Bundles (Save 65%. Use Code: CYBER21BUN)

Pricing:  Pricing is $575 $199

  • Bundle
    • Linux Foundation Node.js Application Development Training (LFW211) + 
    • OpenJS Foundation Node.js Application Development Certification 
  • Bundle
    • Linux Foundation Node.js Services Development Training (LFW212) + 
    • OpenJS Foundation Node.js Services Development Certification Exam (JSNSD)

Certifications (Save 50%. Use Code: CYBER21CC)

Pricing: Pricing is $375 $187.50

View the certification catalog from the Linux Foundation Training and check out the Node.js certifications under the Web and Application Certification section.

You can check out the full details of everything that is on offer on our Cyber Monday Landing Page. Take advantage of the incredible discounts!

Hear from developers who earned the Node.js certification badge on how this program helped increase their confidence and further their careers. 

Prosper Opara, Junior Fullstack Engineer at Deimos Cloud in Nigeria, recently shared his experience with the Node.js Certification. Prosper said the certification greatly helped improve his confidence in his skills as a Node.js developer, and his team members trust him more with Node.js related projects because he’s certified.
Juan Picado, a Senior Front-End Engineer at Adevinta in Berlin gave details about passing the certification exam. He described how it helped him dive more into the specifics of Node.js, and the professional benefits of this vendor-neutral test.

OpenJS Node.js Certification Version Update: Node.js 14 to Node.js 16

By Blog, Certification, Certification and Training, Node.js

The OpenJS Node.js certification exam has been updated with new content today to reflect the latest current, long-term support (LTS) version of Node.js 16, which was released two weeks ago. The certification is ideal for the intermediate Node.js developer looking to establish their credibility and value in their career.

The testing content broadly covers competence with Node.js to create applications of any kind, with a focus on knowledge of Node.js core API’s.

The exams have been updated based on an evaluation of all recent additions to Node.js core APIs, the evolution of the Node.js ecosystem, and continual tracking of industry standards. As a result, candidates will see a few exam questions have been either removed and added within relevant topic areas without increasing exam duration.

To help prepare for the Node.js Certification exams, the Linux Foundation offers training courses for both the Applications and Services exams. The training courses were authored by David Mark Clements, a principal architect, public speaker, author of the Node Cookbook, and open source creator specializing in Node.js and browser JavaScript.

These exams are evergreen and soon after Node.js updates its LTS version line, the certifications are updated to stay in lockstep with that LTS version. Now that Node.js 14 has moved into maintenance, certifications will be based on Node.js 16.

To see what’s new in Node.js 16, check out the Node.js blog by Bethany Griggs, with additional contributions from the Node.js Technical Steering Committee. 

The OpenJS Node.js Certification program was developed over time with community input, and launched two years ago in partnership with NearForm and NodeSource. 

Discounts from 10% – 50% are available for all the OpenJS Node.js trainings and certifications for members of the OpenJS Foundation and supporters of its JavaScriptLandia program. Corporate subscriptions are also available for full access to the Linux Foundation Training and Certification programs.

OpenJS World 2021 Keynote Recap: Node.js: The New and the Experimental

By Blog, Node.js

Bethany Griggs, Node.js Technical Steering Committee member, and Senior Software Engineer at Red Hat, describes in detail how new and experimental features are added to the Node.js project.

Griggs starts the talk with an introduction to Node.js, a highly decentralized open-source project, with no forward roadmap and a heavy activity flow in multiple directions. New features are added to the project based on the interests and requirements of the contributors. She introduces the Working Groups and Teams focused on different areas of the project and the Strategic Initiatives which help smooth operations of the project.

Next, Griggs discusses the project delivery schedule for Node.js. There are two major releases per year with even number releases being promoted to Long-Term Support (LTS). She mentions that each release has three defined release phases. During the Current phase, the release line picks up the non-major changes that land on the Node.js main branch. The Active phase incorporates only the new features, fixes, and updates that have been audited and approved by the LTS team. Only critical bug fixes are part of the Maintenance phase and new features are rarely added in this phase.

In the second half, Griggs introduces a Stability Index, ranging from 0 to 3, which allows users to decide on features to use in their applications. She discusses each index in detail with examples for each of these APIs.

Griggs explains that Stability Index 0 indicates a Deprecated API which may be removed in the future versions of Node.js. An API is first Documentation Deprecated and then elevated to a Run-time Deprecation. Stability Index 3 is for Legacy APIs, which are discouraged from being used in new applications. She assures users that Legacy APIs will not be removed by the project, so applications using these APIs will not be affected.

Experimental APIs have a Stability Index of 1 and may change even in the long-term support phase. She warns that users must use them cautiously in production workloads. She further explains that experimental APIs are ones that do not have an agreed-upon design and are later modified based on user feedback. Stability Index 2 is reserved for Stable APIs for which Semantic Versioning applies and compatibility is a priority. Experimental features only get promoted to stable when the main contributors have confidence in the API and no major changes are likely. She then introduces some new stable features of the project.

In her concluding remarks, Griggs encourages users to look at and provide feedback on the experimental features of the project, which helps the project in speeding up the process of promoting experimental features to stable features. She also warns against the use of experimental APIs in critical applications.

Full Video Here

Broken down by section:

Panel Introduction 0:00

Overview 0:48

Introduction to OpenJS Foundation 1:09

Node.js 1:42

What’s next? 3:07

Working Groups and Teams 4:10

Strategic Initiatives 5:06

Releases 7:26

Deprecated APIs 12:14

Legacy APIs 15:12

Experimental APIs 16:47

Stable APIs 25:31

Conclusion 28:26

Node.js 17 is here!

By Blog, Node.js

This blog was written by Bethany Griggs, with additional contributions from the Node.js Technical Steering Committee and project collaborators.

We’re excited to announce that Node.js 17 was released today!

Node.js 17 replaces Node.js 16 as our ‘current’ release line, with Node.js 16 being promoted to long-term support (LTS) next week. You can expect new releases of Node.js 17 approximately every two weeks, keeping you up to date with the latest features and changes. As an odd-numbered release line, Node.js 17 will not be promoted to LTS. You can read more about our release policy at https://github.com/nodejs/release.

To download Node.js v17.0.0, visit: https://nodejs.org/en/download/current/. Similarly, you can find the release post at https://nodejs.org/en/blog/release/v17.0.0, which contains the list of commits included in this release.

Some of the new changes and features delivered in Node.js 17 include:

  • Additional promisified APIs
  • Stack traces with Node.js version
  • OpenSSL 3.0 support
  • V8 JavaScript Engine is updated to 9.5

Following our Release Policy, new features that are contributed to the runtime are shipped approximately every two weeks in our ‘current’ release line. This means that the majority of new commits that are included in the initial major release (v17.0.0) are those that involve breaking changes. We care about minimizing the number and disruption of these breaking changes for the stability of the platform and to make version migrations easier for our users.

Additional Promisified APIs

A continuing strategic initiative within the Node.js project is to provide promise-based Node.js core APIs. In recent years, we have added the Timers Promises API and Streams Promises API (both available since Node.js 15).

In Node.js 17, we introduce promise-based APIs for the Readline module. The readline module provides an interface for reading data from a Readable stream (such as process.stdin) one line at a time.

The following simple example illustrates the basic use of the readline module:

import * as readline from 'node:readline/promises';

import { stdin as input, stdout as output } from 'process';

const rl = readline.createInterface({ input, output });

const answer = await rl.question('What do you think of Node.js? ');

console.log(`Thank you for your valuable feedback: ${answer}`);

rl.close();

You can read more about the Readline module in the API documentation.

OpenSSL 3.0

Node.js now includes the recently released OpenSSL 3.0, specifically quictls/openssl, upgraded from OpenSSL 1.1.1. OpenSSL 1.1.1 will reach the end of support on 2023-09-11 (from OpenSSL Release Strategy), which is before our proposed End-of-Life date for Node.js 18 (LTS). For this reason, we have decided to include OpenSSL 3.0 in Node.js 17 to provide time for user testing and feedback before the next LTS release.

Among the new features in OpenSSL 3.0 is the introduction of Providers, of which one is a FIPS provider which can be enabled in Node.js. For details about how to build Node.js with FIPS support please see BUILDING.md.

While OpenSSL 3.0 APIs should be mostly compatible with those provided by OpenSSL 1.1.1, we do anticipate some ecosystem impact due to tightened restrictions on the allowed algorithms and key sizes. 

If you hit an ERR_OSSL_EVP_UNSUPPORTED error in your application with Node.js 17, it’s likely that your application or a module you’re using is attempting to use an algorithm or key size which is no longer allowed by default with OpenSSL 3.0. A new command-line option, --openssl-legacy-provider, has been added to revert to the legacy provider as a temporary workaround for these tightened restrictions.

Example usage:

$ ./node --openssl-legacy-provider  -p 'crypto.createHash("md4")'

Hash {
  _options: undefined,
  [Symbol(kHandle)]: Hash {},
  [Symbol(kState)]: { [Symbol(kFinalized)]: false }
}

For more details on the OpenSSL 3.0 release please see the OpenSSL 3.0 release post.

Stack traces with Node.js version

Stack traces are an essential part of diagnosing application errors, helping to provide visibility into what has gone wrong. In Node.js 17, the Node.js version will be included at the end of the stack trace when there is a fatal exception that causes the process to exit.

It’s useful to provide this by default as often when diagnosing reported errors one of the first questions asked will be “What Node.js version are you using?”

Node.js 17 also comes with a command-line option, --no-extra-info-on-fatal-exception, to omit this extra information.

V8 9.5

In Node.js 17.0.0, the V8 JavaScript engine has been updated to V8 9.5. (V8 9.4 is the latest available in Node.js 16).

Along with performance tweaks and improvements, this update comes with additional supported types for Intl.DisplayNames API and Extended timeZoneName options in the Intl.DateTimeFormat API.

You can read more details in the V8 9.5 release post – https://v8.dev/blog/v8-release-95.

Node.js 16 promoted to long-term support

Next week, Node.js 16 will be promoted to long-term support. This is a significant milestone, as many users, particularly those operating production deployments, will opt to only use the long-term supported versions of Node.js. This means for the first time some features will be available in a long-term supported release line.

Node.js 16 and later include Corepack, a script that acts as a bridge between Node.js projects and the package managers they are intended to be used with during development. In practical terms, Corepack will let you use Yarn and pnpm without having to install them. Read more about Corepack in the documentation

In Node.js 16, the V8 JavaScript Engine is V8 9.4. It’s through the V8 JavaScript Engine upgrades that Node.js gains the new JavaScript language features. In Node.js 16, we have gained the following language features:

  • Array.prototype.at (from V8 9.2)
  • ECMAScript RegExp Match Indices (from V8 9.0)
  • Errors with cause (from V8 9.3)
  • Object.hasOwn (from V8 9.3)

Other features new to LTS in Node.js 16 include npm 8 and the Experimental Web Streams API.

Node.js 16 is also the first LTS release where we ship prebuilt binaries for Apple Silicon. We provide separate tarballs for the Intel (darwin-x64) and ARM (darwin-arm64) architectures, with the macOS installer (.pkg) shipped as a fat (multi-architecture) binary.

Other project news

The project is also continuing its Next 10 effort. The goal of this effort is to reflect on what led to success in the first 10 years of Node.js and set the direction for success in the next 10. Initial efforts were focused on defining and documenting the project’s technical values and priorities.

Our next steps on this effort are to host deep-dive sessions on specific topics, with improving documentation and growing our contributions being two of the first topics we plan to discuss.

We welcome you to join our meetings, which can be found on the Node.js Calendar.

Call to Action!

Try out the new Node.js 17 release! We’re always happy to hear your feedback. Testing your applications and modules with Node.js 17 helps to ensure the future compatibility of your project with the latest Node.js changes and features.

Now is also a good time to start planning to upgrade to Node.js 16, which is due to be promoted to long-term support next week. Node.js 16 will continue to be supported until April 30th, 2024.

Also of note is that Node.js 12 will go End of Life in April 2021, so we advise you to start planning to upgrade if you are still using Node.js 12.

For the timeline of Node.js releases, check out the Node.js Release Schedule.

Thank you!We’d like to thank all of the Node.js collaborators and contributors, as this release is a sum of all their efforts.

Specifically, thank you to the Node.js Release Working Group for maintaining and producing Node.js releases and the Node.js Build Working Group for keeping the project infrastructure running.

Retiring the Node.js Community Committee

By Blog, Node.js

This blog was originally authored by Tierney Cyren and posted on the nodejs.org blog on October 7, 2021.

tl;dr: we’re going to be retiring the Node.js Community Committee, moving our existing Initiatives to exist under the Node.js Technical Steering Committee (TSC).

From the Community Committee’s side, we’ve seen a convergence of our initiatives’ goals with the goals of the work that is generally under the TSC. Further, we’ve seen a decline in the number of people who can consistently dedicate the necessary amount of time/energy. As such, separation between the TSC and Community Committee has become more of a barrier to accomplishing our collective goals rather than the helpful and necessary construct it once was.

The Past

I want to start with a bit of history as a form of preservation of the context I’ve collected as the Community Committee’s chair for the majority of its existence.

On January 11th, 2017, Tracy Hinds made the first commit to the nodejs/community-committee repository. This commit was the result of in-person discussion with a number of key Node.js community members at the 2016 North America Collaborator Summit in Austin, Texas, though there’d been a rising discourse to push for something like it for some time in various forums including the (now-archived) Inclusivity WG.

The stated goal of the Community Committee has been to be a top-level commitment of and investment in the Node.js project to support community efforts.

At the time, this was particularly important. Node.js as a project was still figuring out its identity as a project independent from a Corporation while existing in a neutral Foundation. The Node.js community was foundational not only in the project’s success – be it in the v0.x era in the early 2010s, during the io.js fork, or post-reunification – and those starting the Committee wanted to be sure that we were effectively representing and enabling that from the project directly.

The Present

Since the creation of the Node.js Community Committee, members have largely spent project and committee time on outward-facing efforts with the goal of continuing to enable and grow the Node.js community. There’ve been multiple facets to this approach, some of which have been relatively successful and others that have been entirely unsuccessful.

The broad trend that I’ve personally witnessed is that the Community Committee’s interest and activity have slowed dramatically since its inception. My perception is that this is due to a couple of different factors:

  • Sponsorship and Investment:
    • A majority of work in Node.js is done by people who can dedicate non-trivial amounts of their paid time to progress the project, sponsored by their employer. Initially, there was already a small number of people who were able to focus their employer-sponsored time on “community” work – work that doesn’t ship features they need – in Node.js, and that number has only gone down over time.
      • do not think that this will be a universal experience in open source. Several other massive-scale projects are relatively successful in approaching this. They also have fundamentally different models and investment than Node.js does, which is likely a contributing factor to their sustainability. The Electron Outreach WG and the Kubernetes Contributor Experience SIG are both good examples of “success” here, in my opinion.
    • In general, JavaScript occupies a relatively unique space. It is ubiquitous, yet very few companies are willing to substantially invest time, energy, and resources into it despite their reliance on it. Lack of investment into community sustainability is one facet of this.
  • Necessity:
    • The Node.js Community Committee was created at a time in which the Node.js project was larger, with louder voices sharing relatively differing opinions on how we should approach the future. The reality is that we’re smaller now than we were then, and there’s generally less conflict around how we should approach community, safety, and governance. As such, the necessity for a distinct “community” focus is not only less but – in my opinion – actively detrimental to progress. It splits the project’s collaborators into different, disconnected groups rather than unifying the project towards the same goal.
    • The Node.js Community Committee was also created at a time when Node.js was relatively alone. Under the Node.js Foundation, we had to do a lot of community organization within the project directly. Under the OpenJS Foundation, we have shifted several initiatives that the Community Committee was charged with under the Node.js foundation up to the OpenJS Foundation Cross-project Council. As such, certain tasks that we initially envisioned being core to the Community Committee are now living in a different home.

The Future

I don’t believe that retiring the Node.js Community Committee means we’ll see a lack of investment in the community from the Node.js project.

Rather, I think it’s an enabling function for Node.js to continue to sustainably invest in the community. This means fewer barriers, more connectedness, and allowing for resilience in the ebb and flow of those who can invest to do so.

I look forward to what we’ll collectively work on next.

A Big, Heartfelt Thanks

Over the years, we’ve seen dozens of people contribute to the Node.js Community Committee and its initiatives, and I’d like to be explicit:

Y’all have been lovely over the past five years. You all care deeply about the Node.js ecosystem, community, and people. It’s been truly a privilege to have the opportunity to work on something like this with each and every one of you.

As we retire the CommComm, I hope that you see this as yet another evolution of the Node.js project’s commitment to the community… just as the CommComm itself was.