A while back, I wrote about Building Node.js on Windows using the new ClangCL support, which was done on an actual x64 Windows machine. While on vacation with my ARM64 MacBook, I installed Parallels to play Age of Empires II in an ARM64 Windows VM (which worked great by the way). Then I took the opportunity to test my hobby project in Node.js in the VM. The building process was smoother than I expected, though there were still some gotchas.

Recently, I landed a change that moves the Single Executable Application (SEA) build process directly into Node.js core - a hobby project I’d been tinkering with for some time.

In earlier posts, I wrote about reviving require(esm) and its iteration process. The idea seems straightforward once you grasp the ESM semantics, but battle‑testing revealed interop edge cases rooted in existing ecosystem workarounds. Along the way, several escape hatches were devised to address them.

More than a year ago, I set out to revive require(esm) in Node.js and landed an experimental implementation. After a lot of iteration and battle-testing, require(esm) is now unflagged across all supported Node.js LTS release lines (v20.19.0+, v22.12.0+) and has just been marked as stable. This post reflects on how it progressed from experiment to stability. In the next post, I’ll cover implementation details and the interop hatches devised for a smooth ESM transition.

Recently Node.js started to support building with clang-cl on Windows. I happened to have the chance to try it out this week and while it still needs some fixups in my case, it’s mostly working very well now. Here are some notes about this.

Recently, I fixed a macOS-specific startup performance regression in Node.js after an extensive investigation. Along the way, I learned a lot about tools for macOS and Node.js compilation workflows that don’t seem to be particularly well documented on the Internet, so this is my attempt to put more useful information out there in the hope that it can help someone else doing something similar.

In the previous posts we looked into how the Node.js executable was made a bit more reproducible after the Node.js snapshot data and the V8 code cache were made reproducible, and did a bit of anatomy on the unreproducible V8 snapshot blobs. In this post let’s see how we made the V8 snapshot reproducible and finally made the Node.js executable reproducible again on Linux.

In the previous post, we covered how the Node.js built-in snapshot is generated and embedded into the executable, and how I fixed the Node.js bits of the snapshot to make the executable more reproducible. Now we get to the harder part - the binary V8 startup snapshot blob and the code cache were still not reproducible after the aforementioned fix, so it’s time to dig into V8.

In a recent effort to make the Node.js builds reproducible again (at least on Linux), a big remaining piece was the built-in snapshot. I wrote some notes about the journey of making the Node.js built-in startup snapshot reproducible again, hopefully it can help someone else who were trying to do the same thing (or my future self since I have a bad memory) .

Recently, I co-organized a hybrid unconference - the Node.js collaboration summit for 2024 H1. This was the first time I participated in organizing an event like this, and I learned a lot from the experience, so I decided to write this blog post, hoping that it may help others looking into organizing a hybrid unconference.