[DRAFT] Update to Electron 30

[savetheclocktower]

Do not accidentally click any green buttons. We want at least three people on the core team to sign off on this before we land it.

This updates master to the contents of updated-latest-electron, more or less — except for the parts that should not land on master (PulsarNext-specific upload tokens, CI job differences related to release channel, etc.). The commit history in this PR is, uh… artificial, but it saves us from a bunch of low-content commits that do nothing but bump individual dependencies over a period of 2+ years. This is the better way.

This PR will kick off CI tests and should build new binaries in CI; these binaries should be tested as widely as possible. I've got macOS/Apple Silicon covered (and could do macOS/Intel in a pinch, along with Windows 10), but I would love it if other folks stepped up for Linux and Windows just to make sure this works as we expect and nothing explodes. These binaries do not call themselves PulsarNext and do not use a separate home directory, so testing these binaries should also simulate the average user's experience after upgrading to this version; any packages they've got installed with native module dependencies will need to be rebuild before they work, and that could cause headaches, so I'm hoping we can get out ahead of that stuff and have a useful blog post ready when the release drops so that users can be told what to expect.

Things I'd like to settle before landing this:

• A late commit adds atom.trashItem and atom.showItemInFolder, but I think these might be unnecessary; we should try require('@electron/remote').shell.trashItem and require('@electron/remote').shell.showItemInFolder and prefer those if they work.
• The CirrusCI build script wasn't updated on the updated-latest-electron branch to install any of the Wayland-related build dependencies, so I'm not sure if any such binaries built by Cirrus actually support Wayland. I didn't catch this oversight until now. I updated .cirrus.yml to include these dependencies, but if we want to confirm that this results in ARM Linux builds that support Wayland, we'll have to manually trigger a Cirrus job from this PR branch.
• Fix a bug in ppm rebuild as described below. EDIT: Before this PR lands, this other PR from ppm must land and we must update the ppm submodule reference in this PR.

But none of this should preclude review of this PR. Pick it apart! Go nuts! Consume the CI artifacts! We're really close to the finish line here!

Platform sanity checks

• macOS, Apple Silicon
• Linux, ARM64 (tested on Wayland in a VM; keyboard layout detection seems to be accurate)
• Windows 10 (x86)
• Windows 11 (x86)
• Windows 11 (ARM64)
• Linux (x86)

[savetheclocktower]

Some low-hanging fruit in the CI failures; I'll see if I can address them tonight.

[confused-Techie]

Just did a quick skim and noticed some references still to Pulsar-Next.
Since you said part of this PR is no longer defining itself as Pulsar-Next it seemed smart that we remove it wherever we find it. So small potatoes, but it's what I was able to quickly review.

Otherwise installing the binary and will begin testing on Windows 10 & 11

[Spiker985]

I'll see about taking a look at this later today. Apparently the nix shell shenanigans that I used to test Pulsar Next originally is on my desktop and not my laptop that I'm on currently

For anyone unaware, built artifact downloads are linked inside the Build Pulsar Binaries / build * CI jobs, under the Upload Binary Artifacts step

[confused-Techie]

I'm running this as my daily for now for testing on both Win11 and Win10 and haven't noticed anything right off the bat.

What I will mention is there is an unfortunate size increase in the, specifically, "Pulsar Setup.exe" windows installer with:

• 1.130.0: 155MB
• This Bin: 227MB

[confused-Techie]

For anyone unaware, built artifact downloads are linked inside the Build Pulsar Binaries / build * CI jobs, under the Upload Binary Artifacts step

Also a last tip, you must be logged into GitHub to be able to see the download icon on the mentioned page. If you are not logged in, you'll see the zip files and hashes but no way to download

[savetheclocktower]

I added a checklist of platforms against which to do sanity checks. I'm able to check the first three on the list and have done the first two. If you're able to take one of the other platforms, please do, and report back.

By “sanity check” I just mean: download the binary from CI, ensure it runs correctly, and do some basic stuff to test syntax highlighting, file saving, and maybe package installation.

[savetheclocktower]

Another thing that needs fixing:

Rebuilding a package seems like it would work properly within the editor (using the incompatible-packages built-in package and its interface), but it delegates to ppm rebuild under the hood — which has its own bug. On that line, stderr is not in scope, so the interpreter complains about it and throws an error. (I think it's meant to just be return error, since forkNpmRebuild rejects with a string in the case of failure.)

So that definitely needs to be fixed in ppm before we ship.

Separate from that: I had trouble with upgrading x-terminal-reloaded on my Windows 10 machine. I'm going to dig into it tomorrow to figure out the exact cause.

[savetheclocktower]

This is complicated.

I've been trying to find a package that exemplifies the following characteristics:

• uses a native module (or uses a dependency that uses a native module);
• works in both Pulsar (Electron 12) and Pulsar (Electron 30); and hence
• needs only rebuilding of that native module dependency in order to work properly once the user upgrades Pulsar from E12 to E30.

This is actually quite rare! Here's why:

• anything with native module bindings written in N-API does not need rebuilding once you upgrade Node versions;
• most things with native module bindings written in nan are too old to know anything about context-awareness; hence when you upgrade to Electron 30, those packages are marked as incompatible because you're trying to load a non-context-aware module in the renderer. If they were context-aware, rebuilding would need to happen; but since they're not, there's no point in trying to rebuild, because that won't fix the lack of context awareness.

I wasn't aware of the ABI stability feature of N-API — but, sure enough, it's in the docs:

It is intended to insulate addons from changes in the underlying JavaScript engine and allow modules compiled for one major version to run on later major versions of Node.js without recompilation. The ABI Stability guide provides a more in-depth explanation.

When I first upgraded from Pulsar (E12) to Pulsar (E30), I had the incompatible-packages package flag autocomplete-paths (I think?) as needing rebuilding because of zadeh, one of its dependencies. I clicked on Rebuild Packages, had it load for a while, then saw the error message I described above. But once I reloaded the window, the offending package was no longer marked as incompatible, so I assume that the rebuild actually happened successfully despite the error.

But (a) zadeh uses N-API and has from the start, so I might be misremembering this and it was actually some other package; (b) at any rate, I can't get back to whatever state I was in in order to reproduce this. (I didn't grab screenshots or a screencast the first time!) And I can't easily find another package that demonstrates the issue, as I explained above.

So I'm mentioning it here just to keep it on folks’ radar!

[DeeDeeG]

Might have something to do with the precompile cache? ~/.pulsar/compile-cache? I think I had a similar situation that cleared after I did mv compile-cache compile-cache_bak.

[DeeDeeG]

Tested on Windows 11 (x64), looking good so far!

Launched just fine. Syntax highlighting and editing (with reasonable auto-indent behavior) worked fine in some JSON, YAML, MD files in a very quick test. Saving those files and having the editor respond to edits made in Notepad with Pulsar still open also worked fine. Installing atom-clock and dracula-syntax went smoothly and the package/theme worked, respectively. (I couldn't test native code compilation on here since I don't have Python and Visual Studio Build Tools set up on this particular machine.)

Hope to test Linux x64 soonish.

[DeeDeeG]

Good results testing the basics on Fedora Workstation 43 (x64)!

Ditto the above Windows 11 testing report, basically! Substitute nano for Notepad and same notes.

---

That said, I did try installing language-carp, and it failed with:

In file included from ../src/binding.cc:2:
/home/liveuser/.pulsar/.node-gyp/.cache/node-gyp/30.0.9/include/node/node.h:27:2: error: #error "It looks like you are building this native module without using the right config.gypi.  This normally means that you need to update electron-rebuild (>=3.2.8) or node-gyp (>=9.0.0) if you're building modules directly."
   27 | #error "It looks like you are building this native module without using the right config.gypi.  This normally means that you need to update electron-rebuild (>=3.2.8) or node-gyp (>=9.0.0) if you're building modules directly."
      |  ^~~~~

Though I believe we are using node-gyp v10.2.0 directly as part of our forked npm bundled with ppm rather than electron-rebuild or some older version of node-gyp. It installs okay in Pulsar Regular 1.130.1, and doesn't warn about a deprecated or incompatible package upon installing Pulsar-with-Electron-30 over that and launching it, for whatever reason.

tree sitter carp 0 3 0 - install failure log.txt

So, seamless native package support is not necessarily there yet for at least some of the existing packages, at least as of my writing this. Seems the package testing effort remains worthwhile.

[DeeDeeG]

• Fix a bug in ppm rebuild as described below. EDIT: Before this PR lands, this other PR from ppm must land and we must update the ppm submodule reference in this PR.

I made commit 499a100 on another branch; It bumps ppm to include pulsar-edit/ppm#155.

I can push it to this PR's branch or open a separate PR if you'd like.

[savetheclocktower]

I can push it to this PR's branch or open a separate PR if you'd like.

Nah, go ahead and add it to this one!

[savetheclocktower]

That said, I did try installing language-carp, and it failed with:

That's the same error I got last year as catalogued in this issue. I didn't even remember that that happened, but I found the issue upon searching the ppm repo.