Update to Electron 30 #1367
Update to Electron 30 #1367
Conversation
Abandoning support for the legacy Tree-sitter system is a necessary step toward upgrading past Electron 12.2.3.
…and switch all internal usages to `@electron/remote`. This commit also includes the entire bundle of changes to the `tree-view` package — the decaffeination of the `tree-view` specs made it very hard to isolate this change atomically, so I'm reluctantly deciding to bring the whole thing along. `tree-view` has been updated to fix a few bugs with Electron 30 (moving items to the trash, revealing items in the file explorer, etc.) and the specs have been fully decaffeinated (not just machine-decaffeinated).
…and point our dependencies to the NPM-published versions under the `@pulsar-edit` namespace that are compatible with Electron 30.0.9.
This vastly reduces the number of random GitHub commits we're pointing to in our `dependencies` and helps the `resolutions` section be as streamlined as it can be.
Also includes `@electron/remote` and `@electron/rebuild`.
All internal references to paths are also changed in this commit — e.g., `require('foo')` becomes `require('@pulsar-edit/foo')`.
…related to changes in Chromium sometime between Electron 12 and Electron 30. For instance, text bounding-box logic changed at some point to require that our four “sentinel” characters be isolated from one another — otherwise character height/width measurements are inaccurate. Also fixed some issues related to device pixel ratios that resulted in spec failures.
…in favor of a custom solution that uses the `typescript` package directly. `typescript-simple` is no longer updated and is arguably unnecessary anyway; it wasn't hard to replicate its behavior through direct consumption of `typescript`. This preserves our ability to transpile TypeScript just like we can transpile CoffeeScript or `@babel`-ified JS. This is not the happy path of TypeScript transpilation (do it yourself as a build step!) but it's behavior that exists, so we should ensure it continues to work.
…to replace the deprecated `scrollbar-style` module. macOS offers two different “styles” of scrollbar — traditional scrollbars and “overlay” scrollbars that do not use a dedicated scrollbar track. Strangely, we can detect when the user switches from one to the other without any external dependencies… but to find out imperatively which one is currently active, we need a very light module with native bindings. This commit adopts the new approach for detecting which macOS scrollbar style is enabled. Compared to the _status quo ante_, this should carry no behavior change on either macOS or other platforms.
…that probably should have gone in the earlier commit.
…via Electron's standard `crashReporter` interface. Crash reports are enabled on Windows and Linux by default (macOS’s own crash reports via `Console.app` are typically more helpful, but go away if crash reporting is enabled). But you can opt into crash reporting explicitly on all platforms via the `--crashdump` command-line switch.
This option has been removed, and thus no-longer does anything, as of Electron 14. Committer note: This change was split out from the prior commit.
…and disable a Blink experimental feature that was causing trouble with package compatibility (because it added an `on` method to all DOM nodes!).
…in case we want to maintain a `next` (or `nightly` or `preview`) release channel on an ongoing basis.
…so that the specs don't run out of memory. Also be more diligent about cleaning up parsers that we created for a given buffer when that buffer is destroyed.
…and other changes related to release-channel agnosticism. (These should've been included in an earlier commit.)
…and abandon `atom-pathspec` in favor of an internal implementation. (We are pinning to a specific commit of `node-spellchecker`. This one escaped my notice during the context-aware-native-modules sweep — probably because it's in a package! We should revisit this and publish it to NPM instead, but this is likely good enough for now.)
…when the browser can't give us an element under a given X/Y coordinate.
…to include Wayland-related keyboard dependencies. (This probably should be done for the Cirrus builds as well!)
…to include Wayland-related keyboard dependencies. (Untested, but copied directly from the GHA workflow files.)
…now that we're no longer affected by the awful `libuv` bug that was present in Electron 12.
…to support a couple of command-line switches and to build correctly for Electron 30.
|
I have a snapdragon based laptop so if windows arm64 artifact is available I can test it. |
|
OK, if I've done the |
savetheclocktower
force-pushed
the
pristine-pulsar-next
branch
from
9bd738d to
045d660
Compare
|
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. |
|
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 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 |
|
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! |
savetheclocktower
changed the title
|
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. |
|
Tested on Fedora 43 (x86-64) again. On macOS 10.15.7 (x86-64), |
That sounds like developer error! (Me. I'm the developer.) I'll investigate! |
|
@DeeDeeG it was a quick fix — had |
As for these: any error logs you can get me would be quite useful. |
|
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. |
|
OK, good news is that Here's the full output: Output
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 Specifically, the issue is in trying to build (It's true that, when I run So the questions are:
|
|
Also: since there's no compelling reason why a user would need to install We do recommend that people install |
|
I noted above how I wished Upon research, that seems pretty easy to add to ppm install --production steelbrain/linter-ui-defaultThat worked just fine when I tried it, even when So if users actually do run into an issue like this in practice (not being able to install a package because something in |
Thank you! And I have followed up on Discord.
Followed up on Discord.
With regard to this PR, this becomes a bit of a tangent about Yeah, agreed, |
|
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 Original commits pre-force-push are available in a separate branch here: |
DeeDeeG
force-pushed
the
pristine-pulsar-next
branch
from
a910d34 to
964de3a
Compare
DeeDeeG
left a comment
DeeDeeG
left a comment
There was a problem hiding this comment.
I personally believe this is ready for mainline Pulsar, broader promotion in Rolling, and so on.
I'm mainly leaning on practical hands-on testing to say that. Would be great to get it into more users' hands for further testing, and for troubleshooting any additional issues found.
(Big milestone, I've been wanting to be dispassionate about giving a fair review, but yeah, it's kind of a big deal being on so much newer Electron if all goes well. 🤞 )
|
Great! I'll land this tomorrow and get a blog post ready just so users of rolling releases know what to expect. Thanks! |
|
You guys are doing great work. Many cheers. |
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
masterto the contents ofupdated-latest-electron, more or less — except for the parts that should not land onmaster(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:
atom.trashItemandatom.showItemInFolder, but I think these might be unnecessary; we should tryrequire('@electron/remote').shell.trashItemandrequire('@electron/remote').shell.showItemInFolderand prefer those if they work.updated-latest-electronbranch 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.ymlto 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.ppm rebuildas described below. EDIT: Before this PR lands, this other PR fromppmmust land and we must update theppmsubmodule reference in this PR.ppmto 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.EDIT: It's out of draft! I'm actually inclined to land it first, bump theppmversion in this PR, then test the resulting build holistically.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