Bump Electron to latest Electron

[mauricioszabo]

Have you checked for existing feature requests?

• Completed

Modifications

Originally, this was to bump Electron to 13. But considering the effort it took and that it almost worked out of the box for Electron 19, I'm bumping this to move the further we can before other things break down.

Summary

Electron 19 is not working yet. Superstring is the library we need to port to make the editor at least not crash.

I had some luck with Superstring compiled with WASM, but we have some APIs that we need to reimplement (for now, I know of TextBuffer.load) probably on Node (as WASM doesn't have support for native FS unless you do some weird things)

So far, what needs to be done:

• Either port Superstring to NAPI (work in progress here: Migrate to N-API superstring#2) or implement WASM feature that are missing (work in progress here: https://github.com/pulsar-edit/superstring-wasm)
• With superstring compiled to WASM, Autocomplete works but I can't actually SELECT the suggestion with TAB or ENTER. Not sure if it's because of something WASM-related or some breaking change on Electron, needs to investigate
• With WASM, we're not being able to open files (again, because of the missing APIs). We need to fix this
• With WASM, we can save files but they don't appear as modified or saved (missing APIs on superstring)
• Bump TextBuffer to use the newer version of Superstring (either with N-API or with WASM)
• Tree sitter also doesn't work. There, again is some work on porting tree-sitter to N-API but the problem is that all grammars also need to be ported or become context-aware. Maybe a better idea is to just rewrite all of tree-sitter stuff to either use WASM or to simply move to a different implementation
• If we disable tree-sitter for now, we'll need to disable to all packages too, because they open a big red warning about context-aware functions on Pulsar when we boot (even if we DO NOT use them)
• Pathwatcher is also failing. There is a new version that is able to use Pulsar's "watch API" instead, but we need more tests to see if it's working
• Fuzzy-finder is also broken because the API is not context-aware. I removed binary dependencies and drafted a PR to at least make it work on Electron 19
• Git-utils is also broken. This may be a non-issue if we make it context-aware, but it's a good idea to see if we can move git-utils to Isomorphic GIT (a pure JS implementation) and just add a breaking change that the API for atom.repository will become async
• Need to update PPM (and see if its dependencies will also be broken)
• Test the editor, fix tests, etc

Enter your response below:

Ability to keep bumping Electron versions

Any alternatives?

None that I know of

Other examples:

WASM support have trade-offs compared with NAPI. Both are slower than the Nan version Superstring uses, and there's nothing we can actually do - newer Electron versions are context-aware, and superstring uses memcpy to copy text and this will not work anymore;

WASM is better because we just need to compile once, then every place can use the same WASM. It's also worse because WASM requiring is asynchronous, meaning we need to "await" until Superstring is ready to be consumed. Pulsar does not use ESM (which are async) so all requires are synchronous.

[confused-Techie]

In the effort of tracking all of our progress and reducing duplicate work, wanted to advise I am currently working on implementing a pure JavaScript git-utils to help get this fixed here, and ideally allow us simpler git interactions in the future.

[mauricioszabo]

Updates on this:

1. Pathwatcher is now working on Electron 19
2. Git Utils is ALSO working on Electron 19
3. Tree Sitter is broken, and it'll be broken forever - we need to move to the WASM based version, but that means we will break every "language-something" package that uses tree-sitter. Unfortunately, that's inevitable - none of the grammars are context-aware, and I don't think it's sane for us to support all of them. In the process, it may be possible to reimplement tree-sitter with all the modern features it supports (like queries and other things) so that we may be able to just add the grammar in Pulsar and it'll Just Work (famous last words?)
4. Search and Replace is behaving strangely - for some reason, it's replacing some of the elements, but not all of them.
5. I didn't see any performance differences between the wasm-based version of Superstring and the Nan-native one

[alerque]

Electron is now at v33. The version Pulsar currently builds with (v12) has been EOL for over 3 years. v19 has been EOL now for 2 years as well.

I know fixing this is pretty involved, but this is a reminder that this issue is keeping Pulsar out of distros. I was the Arch Linux packager for Atom, still am for Electron, and will be happy to build and release Pulsar in official package repositories if and when it can be built with a currently supported version of Electron.

[mauricioszabo]

@alerque thanks for reaching. We actually have good news on this front: we're just handling infrastructure to offer what we're calling "Pulsar Next", which is Pulsar running in Electron 30.

We have a branch called updated-latest-electron which does offer a binary for Pulsar in Electron 30. I, myself, am daily driving this latest build for some months, to check for crashes and weird behavior, as you can see in this screenshot:

We also have some issues we need to take care before we make it available on our download channels: https://github.com/pulsar-edit/pulsar/issues?q=sort%3Aupdated-desc+is%3Aissue+is%3Aopen+Electron+label%3Apulsar-next. I won't be surprised if we have Pulsar in latest electron in the next months.

So, to summarize: yes, we're working on it, and this "issue" is actually outdated - we're aiming for latest Electron all the time now. I'll update the title and check if there are some duplicated issues about Electron that I can close 👍

[alerque]

Any update on this front? Electron 30 showcased above has been EOL for a while, and 37 in the current release. I don't understand why bringing this up to speed is not the top priority to keep Pulsar viable. If nothing else the Linux distro ecosystem is now deeply into Wayland-only territory and the only hope of getting this project packaged for many distros will be to run on a supported Electron version.

[savetheclocktower]

I don't understand why bringing this up to speed is not the top priority to keep Pulsar viable.

It is the top priority. We all have day jobs and at the moment we don't have all hands on deck. I understand (and share!) your frustration at the slow pace, but I promise you I recognize the urgency.

As that blog post details, the best way to hasten the arrival of the Electron update is to get a few more regular contributors who can review PRs and help out with chores.

[alerque]

Thanks for the link to the blog post, that answers most questions. I would probably have been good to link to it from this issue when it was posted!