pulsar [DRAFT] Update to Electron 30

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:

[x] 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.
[x] 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.
[x] 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.
[ ] As much as it pains me to introduce another blocking task: we really should bump ppm to Node 20.11.1 to match the version of Node that ships with Electron 30. Luckily, this PR is totally green in CI, and I'd be inclined to take it out of draft soon after I do some field tests to verify that it works as well as it seems.

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

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

Oct 27 '25 23:10 savetheclocktower

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

Oct 28 '25 00:10 savetheclocktower

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

Oct 28 '25 06:10 Spiker985

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

Oct 28 '25 23:10 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

Oct 29 '25 07:10 confused-Techie

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.

Nov 03 '25 01:11 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.

Nov 03 '25 07:11 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!

Nov 03 '25 08:11 savetheclocktower

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.

Nov 06 '25 06:11 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.

Nov 06 '25 07:11 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.

Nov 07 '25 00:11 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 https://github.com/pulsar-edit/pulsar/commit/499a1009a6024d58cc2afdee4d9a199c2d2a8739 on another branch; It bumps ppm to include https://github.com/pulsar-edit/ppm/pull/155.

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

Nov 07 '25 02:11 DeeDeeG

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!

Nov 07 '25 05:11 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.

Nov 07 '25 05:11 savetheclocktower

I have a snapdragon based laptop so if windows arm64 artifact is available I can test it.

Nov 10 '25 08:11 namoen0301

OK, if I've done the ppm bump right, CI should soon produce x64 builds that are suitable for evaluation on our various machines. I'll do some jiggery-pokery in CirrusCI tomorrow to accomplish the same for ARM64 builds.

Nov 18 '25 06:11 savetheclocktower

OK, today I generated one-off builds in Cirrus from this PR branch, so go get ’em if you're on ARM64 Mac or Linux! Otherwise, yesterday's CI artifacts from GHA should work just fine as guinea pigs.

Nov 19 '25 08:11 savetheclocktower

A follow-up test on Windows worked great, other than my 2016 gaming rig being slow as hell. After grabbing the CI artifact, I was able to install Pulsar and then successfully run ppm install pulsar-edit/terminal from the shell. Once I reloaded my window, I had a working terminal. This reflects well on the Electron 30 upgrade and the new terminal package.

For as long as it's a separate package, it'll require build tools to install, so that's not any easier for Windows users. But this confirms that there aren't any major gotchas with regard to version compatibility and package authoring. Now that we bumped ppm’s Node version to match that of Electron 30.0.9, ppm won't get tripped up on (e.g.) post-install scripts that assume they're running in a Node 20 environment and therefore use Node 20 APIs.

Nov 20 '25 01:11 savetheclocktower

I also removed Windows ARM64 from the checklist above, since we don't actually distribute such a build.

I'm not well set-up to test this build on Linux x64; maybe @Spiker985 can help with that? Otherwise it's not necessarily a blocker for moving forward.

I think the next step is probably to use this for a few days and make sure there aren't any time bombs, but after that I think it should be ready to land this PR and trigger a rolling release! We can announce something on the blog at that point and wait a couple more weeks to catch bug reports; and if there's nothing show-stopping, we can finally put out a regular release of Pulsar on Electron 30 and crack open the champagne bottles.

With that in mind, I'm taking this out of draft!

Nov 20 '25 01:11 savetheclocktower

Just wanting to report I've been running this version of Pulsar on Win10 & Win11 for 3 weeks, just as standard everyday usage and have not encountered any issues what-so-ever. I'm honestly flabbergasted at how solid this branch is.

Nov 20 '25 02:11 confused-Techie

Tested on Fedora 43 (x86-64) again. atom-clock and dracula-syntax worked, as did x-terminal-reloaded, somehow. Can't get pulsar-edit/termnial to work, though it seems to build successfully without erroring out, at least? Fails to activate due to a missing (JS?) dependency it can't load (called which). language-carp still fails to build.

On macOS 10.15.7 (x86-64), atom-clock and dracula-syntax are working, but I can't get x-terminal-reloaded, pulsar-edit/terminal, nor language-carp to build successfully.

Nov 25 '25 03:11 DeeDeeG

Can't get pulsar-edit/termnial to work, though it seems to build successfully without erroring out, at least? Fails to activate due to a missing (JS?) dependency it can't load (called which).

That sounds like developer error! (Me. I'm the developer.) I'll investigate!

Nov 25 '25 03:11 savetheclocktower

@DeeDeeG it was a quick fix — had which in devDependencies instead of dependencies. Feel free to try again if you like!

Nov 25 '25 04:11 savetheclocktower

On macOS 10.15.7 (x86-64), atom-clock and dracula-syntax are working, but I can't get x-terminal-reloaded, pulsar-edit/terminal, nor language-carp to build successfully.

As for these: any error logs you can get me would be quite useful.

Nov 25 '25 04:11 savetheclocktower

I'm switched daily work to this branch too. I have notived that "ppm install steelbrain/linter-ui-default" doesn't work (node-gyp issue), but in next branch "ppm-next install steelbrain/linter-ui-default" have worked.

Nov 26 '25 19:11 asiloisad

I'm switched daily work to this branch too. I have notived that "ppm install steelbrain/linter-ui-default" doesn't work (node-gyp issue), but in next branch "ppm-next install steelbrain/linter-ui-default" have worked.

Interesting. Thanks for that. I will investigate.

Nov 26 '25 21:11 savetheclocktower

OK, good news is that ppm install linter-ui-default works just fine; it's merely the straight-from-GitHub installation that fails.

Here's the full output:

Output


~ ➜  ppm install steelbrain/linter-ui-default                                                 (Ruby 3.3.0 / Node 20.11.1)
Cloning https://github.com/steelbrain/linter-ui-default.git ✓
Installing modules ✗
> @parcel/[email protected] install /private/var/folders/lq/bjw58qh536q2wt24cfcqfy_80000gn/T/atom-git-package-clone-20251026-91174-htttm1.auuxq/node_modules/@parcel/watcher
> node-gyp-build
CC(target) Release/obj.target/nothing/../../node-addon-api/nothing.o
LIBTOOL-STATIC Release/nothing.a
CXX(target) Release/obj.target/watcher/src/binding.o
CXX(target) Release/obj.target/watcher/src/Watcher.o
CXX(target) Release/obj.target/watcher/src/Backend.o
CXX(target) Release/obj.target/watcher/src/DirTree.o
CXX(target) Release/obj.target/watcher/src/watchman/BSER.o
CXX(target) Release/obj.target/watcher/src/watchman/WatchmanBackend.o
CXX(target) Release/obj.target/watcher/src/shared/BruteForceBackend.o
CXX(target) Release/obj.target/watcher/src/unix/fts.o
CXX(target) Release/obj.target/watcher/src/macos/FSEventsBackend.o
SOLINK_MODULE(target) Release/watcher.node

[email protected] install /private/var/folders/lq/bjw58qh536q2wt24cfcqfy_80000gn/T/atom-git-package-clone-20251026-91174-htttm1.auuxq/node_modules/msgpackr-extract
node-gyp-build-optional-packages


[email protected] install /private/var/folders/lq/bjw58qh536q2wt24cfcqfy_80000gn/T/atom-git-package-clone-20251026-91174-htttm1.auuxq/node_modules/lmdb-store
node-gyp-build

CXX(target) Release/obj.target/lmdb/src/node-lmdb.o
npm WARN deprecated @babel/[email protected]: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-export-namespace-from instead.
npm WARN deprecated @babel/[email protected]: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-class-properties instead.
npm WARN deprecated @babel/[email protected]: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-logical-assignment-operators instead.
npm WARN deprecated @babel/[email protected]: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-numeric-separator instead.
npm WARN deprecated @babel/[email protected]: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-json-strings instead.
npm WARN deprecated @babel/[email protected]: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-optional-chaining instead.
npm WARN deprecated @babel/[email protected]: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-nullish-coalescing-operator instead.
npm WARN deprecated @babel/[email protected]: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-private-property-in-object instead.
npm WARN deprecated @babel/[email protected]: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-private-methods instead.
npm WARN deprecated @babel/[email protected]: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-export-namespace-from instead.
npm WARN deprecated @babel/[email protected]: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-logical-assignment-operators instead.
npm WARN deprecated @babel/[email protected]: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-class-static-block instead.
npm WARN deprecated @babel/[email protected]: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-async-generator-functions instead.
npm WARN deprecated @babel/[email protected]: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-optional-chaining instead.
npm WARN deprecated @babel/[email protected]: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-dynamic-import instead.
npm WARN deprecated @babel/[email protected]: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-object-rest-spread instead.
npm WARN deprecated @babel/[email protected]: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-unicode-property-regex instead.
npm WARN deprecated @babel/[email protected]: This proposal has been merged to the ECMAScript standard and thus this plugin is no longer maintained. Please use @babel/plugin-transform-optional-catch-binding instead.
npm WARN deprecated [email protected]: The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
npm WARN deprecated [email protected]: babel-eslint is now @babel/eslint-parser. This package will no longer receive updates.
npm WARN deprecated [email protected]: Modern JS already guarantees Array#sort() is a stable sort, so this library is deprecated. See the compatibility table on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort#browser_compatibility
npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated [email protected]: core-js@<3.23.3 is no longer maintained and not recommended for usage due to the number of issues. Because of the V8 engine whims, feature detection in old core-js versions could cause a slowdown up to 100x even if nothing is polyfilled. Some versions have web compatibility issues. Please, upgrade your dependencies to the actual version of core-js.
npm WARN deprecated [email protected]: See https://github.com/lydell/source-map-resolve#deprecated
npm WARN deprecated [email protected]: this library is no longer supported
npm WARN deprecated [email protected]: Please upgrade  to version 7 or higher.  Older versions may use Math.random() in certain circumstances, which is known to be problematic.  See https://v8.dev/blog/math-random for details.
npm WARN deprecated [email protected]: Use your platform's native atob() and btoa() methods instead
npm WARN deprecated [email protected]: Use your platform's native DOMException instead
npm WARN deprecated [email protected]: request-promise-native has been deprecated because it extends the now deprecated request package, see https://github.com/request/request/issues/3142
npm WARN deprecated [email protected]: Use your platform's native performance.now() and performance.timeOrigin.
npm WARN deprecated [email protected]: https://github.com/lydell/resolve-url#deprecated
npm WARN deprecated [email protected]: See https://github.com/lydell/source-map-url#deprecated
npm WARN deprecated [email protected]: Please see https://github.com/lydell/urix#deprecated
warning: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: archive library: Release/nothing.a the table of contents is empty (no object file members in the library define global symbols)
In file included from ../src/node-lmdb.cpp:1:
In file included from ../src/node-lmdb.h:30:
/Users/andrew/.pulsar/.node-gyp/Library/Caches/node-gyp/30.0.9/include/node/node.h:27:2: 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."
|  ^
1 error generated.
make: *** [Release/obj.target/lmdb/src/node-lmdb.o] Error 1
gyp ERR! build error
gyp ERR! stack Error: make failed with exit code: 2
gyp ERR! stack at ChildProcess. (/Applications/Pulsar.app/Contents/Resources/app/ppm/node_modules/node-gyp/lib/build.js:216:23)
gyp ERR! System Darwin 23.6.0
gyp ERR! command "/Applications/Pulsar.app/Contents/Resources/app/ppm/bin/node" "/Applications/Pulsar.app/Contents/Resources/app/ppm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /private/var/folders/lq/bjw58qh536q2wt24cfcqfy_80000gn/T/atom-git-package-clone-20251026-91174-htttm1.auuxq/node_modules/lmdb-store
gyp ERR! node -v v20.11.1
gyp ERR! node-gyp -v v10.2.0
gyp ERR! not ok
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: @msgpackr-extract/[email protected] (node_modules/msgpackr-extract/node_modules/@msgpackr-extract/msgpackr-extract-linux-arm):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for @msgpackr-extract/[email protected]: wanted {"os":"linux","arch":"arm"} (current: {"os":"darwin","arch":"arm64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: @msgpackr-extract/[email protected] (node_modules/msgpackr-extract/node_modules/@msgpackr-extract/msgpackr-extract-darwin-x64):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for @msgpackr-extract/[email protected]: wanted {"os":"darwin","arch":"x64"} (current: {"os":"darwin","arch":"arm64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: @msgpackr-extract/[email protected] (node_modules/msgpackr-extract/node_modules/@msgpackr-extract/msgpackr-extract-linux-x64):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for @msgpackr-extract/[email protected]: wanted {"os":"linux","arch":"x64"} (current: {"os":"darwin","arch":"arm64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: @msgpackr-extract/[email protected] (node_modules/msgpackr-extract/node_modules/@msgpackr-extract/msgpackr-extract-linux-arm64):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for @msgpackr-extract/[email protected]: wanted {"os":"linux","arch":"arm64"} (current: {"os":"darwin","arch":"arm64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: @msgpackr-extract/[email protected] (node_modules/msgpackr-extract/node_modules/@msgpackr-extract/msgpackr-extract-win32-x64):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for @msgpackr-extract/[email protected]: wanted {"os":"win32","arch":"x64"} (current: {"os":"darwin","arch":"arm64"})
npm WARN [email protected] requires a peer of eslint-plugin-react-hooks@^4 || ^3 || ^2.3.0 || ^1.7.0 but none is installed. You must install peer dependencies yourself.
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] install: node-gyp-build
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/andrew/.pulsar/.apm/_logs/2025-11-26T23_19_51_267Z-debug.log

The difference between installing from the package repo and installing from GitHub is presumably that, in the latter case, we check the repo out locally and run npm install, meaning devDependencies are installed as well. (That said, it would be nice if we could avoid that! npm probably does it because it assumes it has to run the build script to produce the same effects that installing from NPM would have… but we likely don't need to, since the code payloads of packages come straight from the repo.)

Specifically, the issue is in trying to build lmdb-store, which is a dependency of @parcel/watcher, which itself is a dependency of parcel. parcel is the bundling tool used by linter-ui-default.

(It's true that, when I run ppm-next install steelbrain/linter-ui-default, I don't get this exact error… but instead I get a different error later in the process related to npm not being found. This is because this package’s prepare task is npm run get.linter-types && npm run build, and there's no npm on my path by default because I use asdf to manage Node versions. As an aside: we should probably fix this by adding the directory of our own copy of npm to the PATH when we run stuff.)

So the questions are:

Why doesn’t lmdb-store compile/rebuild successfully on Node 20.11.1?
Why does it rebuild successfully on Node 16.0.0 (which is what PulsarNext’s version of ppm was using)?
Can we update node-gyp (as the error message implies) in order to resolve this issue?
Separately from that, can we make it so that ppm skips trying to install devDependencies when installing straight from a GitHub repo?

Nov 26 '25 23:11 savetheclocktower

Also: since there's no compelling reason why a user would need to install linter-ui-default straight from GitHub, I don't think this is a blocker for landing this PR.

We do recommend that people install linter from source via ppm install steelbrain/linter, but I just tested that and it works fine.

Nov 26 '25 23:11 savetheclocktower

I noted above how I wished ppm install foo/bar would install just the dependencies, not the devDependencies.

Upon research, that seems pretty easy to add to ppm, so I'll put that on my to-do list. But there's a way to do it explicitly:

ppm install --production steelbrain/linter-ui-default

That worked just fine when I tried it, even when ppm install steelbrain/linter-ui-default failed.

So if users actually do run into an issue like this in practice (not being able to install a package because something in devDependencies fails to build) we've got a workaround for them.

Nov 27 '25 01:11 savetheclocktower

@DeeDeeG it was a quick fix — had which in devDependencies instead of dependencies. Feel free to try again if you like!

Thank you! And I have followed up on Discord.

As for these: any error logs you can get me would be quite useful.

Followed up on Discord.

I noted above how I wished ppm install foo/bar would install just the dependencies, not the devDependencies.

(That said, it would be nice if we could avoid that! npm probably does it because it assumes it has to run the build script to produce the same effects that installing from NPM would have… but we likely don't need to, since the code payloads of packages come straight from the repo.)

With regard to this PR, this becomes a bit of a tangent about ppm, so IMO it's not really a blocker for this PR itself, but...

Yeah, agreed, prepublishOnly sort of scripts shouldn't really have a separate role to play for a Pulsar package, beyond the usual prepare or postinstall scripts, given we have no separate "pre-prepared tarball registry" (npm package registry) for Pulsar packages in and of themselves. So, the special handling of git cloned packages only adds complexity and strange new requirements/edge cases to handle, it seems. Would probably be good to just install production deps and run only the equivalent lifecycle scripts that would have run for a package from the npm registry.

Nov 27 '25 20:11 DeeDeeG

As discussed on Discord: I'm pushing with updated attribution (commit author metadata) on the 1st two commits . . . and separating the deletion of the deprecated app.allowRendererProcessReuse = false option on the main process into its own commit, as discussed in a comment thread above (since the option has been removed and doesn't do anything anymore in Electron 14+, but wanted in its own commit to make it harder to miss in case shuffling around different branches, etc...)

Original commits pre-force-push are available in a separate branch here: pr-167-old (tip of branch is at a910d34ede0df9fc7630b0d4b4b0a37151393634).

Dec 01 '25 01:12 DeeDeeG