Recently I’ve found myself repeating the same explanations to different people about how to test a V8 patch in Node.js, how to patch the Node.js fork run in V8’s integration CI, or how to get these patches into their repositories/CIs. I’ve also been helping out with some of the V8 maintenance tasks in Node.js recently, which refreshed some of my knowledge about how things work these days. To reduce the parrotting, here is my attempt to write down the current state of things, the challenges I’ve observed and some tips on how to handle cross-project patches.

Recently I landed a custom Python gdb unwinder in V8 that allows gdb to unwind through V8’s JIT-compiled frames on x64. During the process, I ended up digging into gdb’s internals to figure out how to properly implement the unwinder. Here are some notes about it and hopefully it can be useful for others who want to implement similar things for their own JITs.

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.