What’s New With Node? Interview With Bethany Griggs, Node.js Technical Steering Committee

Node.js 14 is available now. We wanted to get more context and details about the state of Node, and why developers should care about Node.js 14. We talked with Bethany Griggs, Node.js Technical Steering Committee member and Open-source Engineer at IBM, to find out more. 

Bethany has been a Node Core Collaborator for over two years. She contributes to the open-source Node.js runtime and is a member of the Node.js Release Working Group where she is involved with auditing commits for the long-term support (LTS) release lines and the creation of releases. 

Bethany presents and runs workshops at international conferences, including at NodeSummit, London Node.js User Group, and NodeConfEU.

So, you’ve been working as a Node Core collaborator for 2 years, how have things changed? What have you seen from your point of view?

One of the biggest changes is the emphasis on onboarding new contributors to major parts of the project. Getting new names and faces onboarded in a position where they can contribute to Node and also an increase in socializing how people can contribute. 

That means onboarding new feature contributors, contributors to Node.js core, and also onboarding contributors into the specific working groups, such as the Release Working Group and the Package Maintenance Working Group. 

There’s also been several code-and-learn events at various conferences. This is where existing collaborators and contributors mentor attendees through one of their first contributions to Node.js.

Where should people go to get started contributing? 

Go to Node ToDo — it’s a website that walks you through a path towards your first contribution to Node.js. As long as you're a little bit familiar with Node.js, you can start here. 

The other option is to look for labels in the Node.js GitHub repository tagged with "Good first issue". 

What are the biggest challenges for Node.js Core this year? 

I think keeping up with the volume of activity in general. We typically have 5-10 pull requests opened on GitHub per day, with most of the new commits landing on master. From master, the commit lands in the current release line. After that, each commit gets audited for suitability for the LTS release lines. So we’re maintaining three different release lines at a time and having a constant flow of incoming pull requests to keep up with.

We’re maintaining the LTS release lines with our enterprise users in mind. The LTS release lines provide them with stability — meaning they’re not having to deal with breaking changes so often. Corporate upgrade schedules are normally more traditional and longer, so we have to provide LTS releases to take into account the steady schedules of large enterprises.

In order to handle this, we currently have 100 active collaborators who can review and land PRs. And we have active mentorship to bring in more contributors and are also actively mentoring new releasers so that they can help out with the auditing. 

The package maintenance team was announced last year – Has Node.js package maintenance improved? 

The package maintenance team is still going through the phase of documenting best practices and getting the opinions of enough module maintainers to create those best practices and those guides. You need to set this groundwork first. We can see some adoption of our best practices, such as testing across Node.js versions. 

I don’t think we’re quite at the point where it has widely improved because we’re still trying to define the best practices. We’re trying to onboard as many maintainers, authors, and consumers as possible when curating these best practices so that we consider as many situations and use-cases as possible.

Do you have an example where the Package Maintenance Working Group has helped?

We used Express.js as one of our pilot projects. And we’ve successfully created a triaging effort via the Package Maintenance Working Group. Express is very popular. They have many, many repositories in Github where people raise issues and the maintainers can struggle at times to keep up with how many issues were raised. 

Some issues are actual bugs reported, some are just, “Hey, I’m not sure how to use Express, or this particular API.” So, via Package Maintenance, we started a triaging effort where people could volunteer to help triage the issues for Express. The Package Maintenance team is trying to define the process and structure of how you can get help triaging your own issues.

The Package Maintenance team is trying to come up with some best practices and processes for maintainers or module authors to follow when they need help, or can no longer dedicate time to maintaining their module.

Members of the Package Maintenance group can get involved with defining the best practice documentation and guides. But it’s also possible to get involved with the triaging efforts via Package Maintenance, so signing up to triage issues for modules such as Express.js.

What’s new in Node.js 14, and why should I upgrade?

One of the main features is the V8 upgrade. Most major releases of Node.js come with a major V8 upgrade. Node.js 14 bumped it to V8 8.1. The main features that come with V8 8.1 include Optional Chaining, which is a relatively recent JavaScript language feature that went through Ecma TC39 in the past few years. 

Long chains of property accesses in JavaScript can be error-prone, as any of them might evaluate to null or undefined. These are known as “nullish” values. Checking for property existence on each step easily turns into a deeply-nested structure of if-statements or a long if-condition replicating the property access chain. Optioning Chaining basically simplifies the code required here and has already been implemented in some other languages.

Another nice improvement is the nullish coalescing operator, ??. A new short-circuiting operator meant to handle default values has been added, so that when true or false values in JavaScript aren’t clearly defined. Values for && and || don't fit in every scenario, and this can lead to hard-to-understand bugs. 

Also, there are some international date-time format additions and more.

One other thing to point out: You should take caution before upgrading your production applications to use Node.js 14. Until Node.js 14 is LTS, there will be slightly more churn and feature additions. I’d personally recommend holding off upgrading to Node.js 14 until it is promoted to LTS in October 2020, particularly for critical production applications. 

However, now is a great time to get ahead and start testing your applications or modules on Node.js 14 and also try out some of the new features. This will test your migration path to Node.js 14, your transition to using Node.js 14 when it is promoted to LTS will go more smoothly if you’ve been already testing with it in advance.