Bump Electron to 32.3.3

[savetheclocktower]

This is in draft until I'm sure that there are no more weird chores to do.

Once I bumped Electron, @pulsar-edit/fuzzy-native failed to compile. I fixed a couple issues by updating nan and node-abi, then I fixed the rest by ensuring that @pulsar-edit/fuzzy-native used C++20 rather than C++17.

Then better-sqlite3 complained, but I was able to address that by installing a newer version. It is a new major release, though, so the specs will tell me if that broke anything.

[savetheclocktower]

So I bumped @pulsar-edit/fuzzy-native because it was failing to compile. I got complaints about needing C++20 support, and I figured that was easy enough; In its binding.gyp I changed -std=c++17 to -std=c++20 and got it to build.

That worked on my local machine. But not in CI! We use Docker in CI for our Linux binary-building jobs so that we can build against Debian 10 in order to get the broadest possible glibc compatibility. But that means we end up building using an older gcc that does not support c++20.

Our options, then, are

1. Figure out how to build with a newer gcc on Debian 10 (which might defeat the purpose of casting a wide glibc net);
2. Figure out how to customize the binding.gyp in @pulsar-edit/fuzzy-native (or override it) so that it uses -std=c++2a instead of std=c++20 (which might be enough to get fuzzy-native to compile);
3. Bump our Docker image to a slightly newer version of Debian that can grok C++20 (which I'm unwilling to do while @DeeDeeG is away, since they're much more knowledgable about the trade-offs involved in that decision);
4. Understand exactly what changed such that C++20 is now required to build @pulsar-edit/fuzzy-native.

I'm going to try option 4. I should've understood this better before I bumped @pulsar-edit/fuzzy-native in the first place; it seemed strange.

Another option is to take this opportunity to migrate @pulsar-edit/fuzzy-native from nan to N-API.

[savetheclocktower]

That's to say nothing of the Windows failure while building spellchecker. Maybe we should migrate https://github.com/pulsar-edit/node-spellchecker to N-API while we're at it!

[savetheclocktower]

OK, here's the deal after some more research:

• V8 started requiring C++20 at a certain point (hard to pin down when that happened, but one of the 12.x releases)
• Electron adopted that requirement implicitly once it bumped to a V8 version that hard-requires C++20 in v8config.h
• Electron 32.3.3 bundles Node 20.18.1, but whereas the standalone Node 20.18.1 release used V8 11.3, Electron 32.3.3 uses V8 12.8 (which I think was first used by Node in 23.0.0, if not sometime in the Node 22 release cycle); thus it applies stricter criteria than standalone Node 20.18.1 itself
• This is why @pulsar-edit/fuzzy-native compiles just fine against Node 20.18.1 in isolation, but fails to compile during electron-rebuild

So it's looking like the correct course of action is, indeed, Option 3 as described above. At any rate, this is just a preview of something we were going to need to do anyway once we moved to a version of Electron that used Node 24 (which should be just two or major Pulsar releases away, I hope).

So now that I understand why @pulsar-edit/fuzzy-native needed to bump to -std=c++20, it's making more sense.

So how far should we bump our Debian 10 Docker image? Claude suggests Debian 12 — because apparently Debian 11 bundles gcc version 10, whose C++20 support is… experimental, I guess? Whereas Debian 12 bundles gcc version 12.

That said, I would love to figure out a solution that doesn't couple gcc and glibc updates. Right now we deliver Pulsar to anything that supports glibc 2.28 2.31 or greater. Perhaps we could figure out how to use Debian 11 (for glibc 2.31) but install a newer gcc that speaks C++20 properly. That would allow us to keep support for even old-ish Linux distros like Ubuntu 20.04. (EDIT: Our setup was designed to ensure support for glibc ≥ 2.28, but at some point Electron itself started requiring glibc ≥ 2.31. So if we stick with Debian 11, nothing will change in that respect!)

Whereas if we just jump to Debian 12, we'd be ending support for Ubuntu 20.04, RHEL 8, and the like. (I don't know how many people that would affect. I do kinda wish we had a sense of the spread of various distros used across our Linux user base.)

I don't like ending support for older stuff because I know that at least a few users are affected every time. But then we've extended more grace than Chromium or most other Electron apps simply by having lagged behind the latest releases for so long — so this was always going to happen.

I'll explore the Debian 11 route first just to see if we can soften the blow.

[savetheclocktower]

OK, Windows is still failing (for spellcheck reasons) but the Linux builds are now at least completing. (I haven't tested them yet, but feel free to give them a whack if you're curious and report back.)

Claude is better than I am at devops and Linux things. I floated the idea of updating Debian a little (to version 11) but then trying to use a newer gcc than what stock Debian 11 gives us. Claude suggested these two options:

• Pull .debs directly from a Bookworm snapshot (snapshot.debian.org) and install with dpkg -i + manually satisfy deps — fragile, since Bookworm's gcc-12 package wants a newer libc6-dev/cpp-12 than Bullseye ships, which can cascade into pulling in newer glibc-dev anyway (partially defeating the point of staying on Bullseye).
• Use a self-contained relocatable toolchain that targets old glibc but speaks new C++ standards — e.g., conda-forge's gcc/gxx compiler packages, or a vendored static toolchain (Holy Build Box-style). This is the standard trick projects use to decouple "glibc floor" from "C++ standard support": install a self-contained GCC 12/13 via conda/micromamba into the container, set CC/CXX to point at it for the yarn build/electron-rebuild step, while the system glibc stays at Bullseye's 2.31. This is more setup but is the only approach I can vouch for with confidence — it's load-bearing infrastructure for tools like manylinux for exactly this glibc/GCC decoupling problem.

I went with option 2. Oddly, Claude was adamant that this version of gcc was only needed for the electron-rebuild step, and not for yarn dist or anything else, so that's what I went with. After a lot of back-and-forth about what needed to be abstracted away between x86 and ARM jobs, eventually both of them worked.

Now, if this works, it naturally makes one wonder whether we should just stay on Debian 10. But Claude thinks that Electron 32's own official Linux binaries are built against Debian 11 and cites these sources. So Electron's own prebuilt binaries seemingly require glibc 2.31. Therefore bumping to Electron 32 will theoretically end some Linux support, but only a bit: anything based on RHEL 8, like Almalinux 8. (I am reminded that we only build on Debian 10 in the first place because an Almalinux 8 user complained, but that was in 2023 and I've got to hope they've upgraded by now!) EDIT: Actually, our own website already states that we require a minimum of glibc 2.31; at one point we went back to 2.28, so I've got to assume that it was the upgrade to Electron 30 that ended support for 2.28.

And, again… short of someone maintaining a “Legacy” Pulsar version that gets backports, there is no alternative, because the glibc 2.28 train is leaving the station. So I think the Debian-11–plus–conda-forge’s-gcc approach is the best compromise for now, assuming it actually works. I'll see if I can get the CI binary running on my Linux VM later.

In other news, I managed to rewrite @pulsar-edit/fuzzy-native in N-API, and I'm going to tackle spellcheck next. No reason why we can't turn this crisis into an opportunity!

[savetheclocktower]

I was able to do a simple smoke test in my Linux VM with the generated Linux ARM64 binary, so I'm counting that one as a success.

I just pushed a commit that points the spellchecker dependency to the rewritten N-API version, so we'll see if that fixes Windows.

[savetheclocktower]

Ignore the weirdness of GitHub thinking that one package test is still in progress (it isn't; it passed). We've got green on all platforms. If someone could sanity-check the Windows binary that'd be great, since I'm not set up to do that easily.

This will stay in draft until all the bumps are done properly. Prerequisites for this coming out of draft:

• @pulsar-edit/fuzzy-native releases a new major version using N-API and compatible with modern Node/V8.
• We release our own fork of spellchecker at @pulsar-edit/spellchecker, bumping the major version, so that it uses N-API and is compatible with modern Node/V8.

Prerequisites for landing:

• @DeeDeeG assesses all the CI choices I've made (using a Debian 11 image with a newer gcc from conda-forge) and either agrees with them or suggests how they can be streamlined.

Post-landing tasks:

• Add an item to the release checklist reminding ourselves to update the OS requirements for Linux on the website… actually, no. I thought the website would've said that Electron requires glibc 2.28 or greater, but it already says 2.31. So that won't change. Maybe that glibc bump happened at the same time as the Electron 30 upgrade.