As usual, when the release notes for a new version of a runtime come out, we have a bunch of updates regarding very internal and transparent bits (at least to us, as users of the runtime).

However, with the release notes of Node.js 19, we have some interesting gems that if you don’t care to look at in detail, you probably missed from the announcement.

So let’s take a look at what are the most exciting parts of the changes announced with version 19 of our favorite JavaScript runtime.

We now have a WATCH flag

Granted, it’s still in experimental mode, but at least we can say we have the beginnings of a watch flag. Does that mean Node is slowly taking some cues from the Deno team?

In case you’re not aware, Deno took a different approach from Node when they designed their CLI. Instead of just giving their users a minimalistic way of running their scripts, the Deno team gives you everything you need on a single executable.

That means file watcher, test runner, code prettifier, and more. It’s definitely a different approach from what Node has been doing for the last decade, but it seems to be working. After having some conversations with Deno developers I can see the appeal of having a single place where all of these tools are coming from.

So can we safely say that this is but the first step of many in the path of integrating a lot of tools that have been developed by the community, into their own CLI tool?

Hard to say, we could be looking at a similar approach yes, but it could also be just a one-off.

In particular, this flag is interesting because by default it’ll watch your entry point file AND any required or imported dependencies. If you want to watch a specific folder for changes (I’m assuming like watching for changes on config files), you’ll have to specify the watch-path flag which is also in experimental stage.

And right now there is not a lot we can do with it, once on “watch mode”, when a change is detected, the Node.js process will be restarted. That’s it.

Don’t get me wrong, it’s a lot already, but it would also be nice if we could somehow hook up to that event, and do some other interesting tasks around it.

Oh well, maybe next version!

Custom ESM Resolution Adjustments (don’t skip this one!)

When I read this title I immediately skipped over it, because I really thought it was like an internal flag that was removed, I didn’t really care too much about it.

And then I actually followed some links and read what this change was about.

You see, while the name might be a bit cryptic if you’re not a core Node.js developer, the functionality is not. How many times did you require a file in Node like this?

const myPkg = require("./folder/file")

Notice the lack of extension there, since we all know that Node will look for many alternatives before giving up.

Or perhaps directly referenced a folder like this:

const myPkg = require("./my-folder")

This would work if you had a file called index.js inside that folder. Node would automatically look for it.

But that’s not the case if you try to import the same package. Node’s “ESM specifier resolution” doesn’t support any of those extra behaviors. Instead, if you don’t directly specify the file (with the correct extension), you won’t find it.

You could mimic the CommonJS behavior by using the flag --experimental-specifier-resolution=node , and that would work. But then again, that’s a long and ugly flag with the word “experimental” on it. Good luck convincing your users that this is safe to execute!

Lucky for you, now in Node.js 19 this is no longer a problem. With the new loader you can do things like these and they will work:

import file from './file' //as long as "file" has the right extension

import myFile from './folder' //if "folder" has an "index.js" inside

See? The name of this update made it seem like something else, but instead, it’s a very nice and welcomed DX fix.

Did you like what you read? Consider subscribing to my FREE newsletter where I share my 2 decades’ worth of wisdom in the IT industry with everyone. Join “The Rambling of an old developer” !

We also have a new version of V8 working with us

We went from using version 10.2 to version 10.7

Who cares right?

Well, you might! You see, aside from the fact that these updates in versions keep Node.js using the latest release of the runtime and it makes sure we don’t fall behind, this particular version introduces a new update from a Stage 3 proposal for ECMAScript: updates on the Intl.numberFormat API.

It’s always exciting when we get to play with new features from the language, but this particular one is very interesting if you’re dealing with numbers in your project.

Amongst other things, they improve the precision of some of the existing methods and added new formatting options. While still officially in Stage 3, the proposal can already be tried and tested using the latest version of Node, so give it a go!

We’re losing DTrace/SystemTap/ETW Support

In case you’re not aware, DTrace, SystemTap and ETW are profiling tools that work on different OS and there was an internal effort from the Node.js team to keep the runtime compatible and working with all of them.

That way you could use these external tools to profile and understand how your Node.js-base code performed under different circumstances.

However, according to the announcement, the effort to keep them alive and updated was too much compared to the usage/benefit that it brought to Node users.

So it’s gone.

Were you taking advantage of this in the past? What are you going to do now?

There are other updates if you look at the announcement, but honestly, these were the ones that really caught my eye. Especially the ones that required me to dig a little bit to understand them.

Are you excited about the changes on Node.js 19? Leave a comment describing how they affect you! I’m always happy to read about how people are using Node!