It's time for Flathub!
We've been talking about going on Flathub for, well... quite a while at this point. So I took the initiative!
This took waaaaay longer than expected, multiple days actually. And I thought differently each time.
Approach No.1
I decided to follow exactly what the standard Electron Sample app did. This turned out to be a mistake. Some people did get it to work, but I didn't really get it to work that well, so I had to use manual workarounds.
Blocker: No network access
I realized that Flathub builds had no network access. How the sample app mitigated this was by using flatpak-node-generator, that would take a package-lock.json, and generate a JSON that flatpak-builder could use to download necessary libraries before the build starts, because AFTER a build starts all network access is pretty much gone. But when I used NPM install to install the dependencies in the first place; nothing worked. It would constantly attempt to get binaries from online; which it couldn't access. So I grinded and thought it was all my fault (which was another big mistake).
So, I spent some time... and failed. But then, I knew I needed to think out of the box!
Approach No.2
I tried searching for Electron apps already on Flathub. One was the Nuclear audio player, which had already got on Flathub and was FOSS, so the JSON (which I changed into a YAML) was ready for me to use!
The way Nuclear.js did it was by storing an already-prebuilt, unpacked build on GitHub Releases. The JSON would then download that and package it into a Flatpak, reducing the need for any dependencies at all down to nearly none.
I tried this, and it didn't work out of the box obviously, but after some reiterations, I got it to work. Finally. And the Flathub bot greeted me with a "test build succeeded" message after several failed builds.
Blocker: The open-source rule
But then, the storm came. I forgot all about a Flathub rule of thumb: If an app is open source, it MUST be built from source!, so the reviewer can verify that the code it uses is safe, rather than trusting a black box, which makes a lot of sense honestly, but it was annoying... I thought this would occur, so at first I thought of using a tarball with node_modules already inside and all needed dependencies available, so NPM install would be mitigated and only the builder would need to work. But I thought the tarball would be too big. This is a... really big mistake. Even IF something is big, you've gotta get some prototype working first. Whether it relies on a 2GB tarball (thankfully the vendored tarball was less than a QUARTER of that size!), or the most absurd Base64 workaround of all time; everyone has to start somewhere.
So I told my reviewer Hubert about the situation. He suggested the same vendored tarball approach I had neglected earlier. And so, here came the final stretch.
Approach No.3
I decided to just cope and use the vendored tarball approach, and move a few files upstream to reduce clutter (as Hubert suggested). I needed a usable Electron ZIP, so I found a leftover from the Linux unpacked build on my local box, and the arm64 one was on the official Electron repository (I only added arm64 support later though, due to the second approach using an x64-only binary like Nuclear did; it was a clear-cut clone.)
And so, I uploaded my large tarball to GitHub Releases (and retagged several times; don't do that!), and added it as a source in the YAML. After this, I tried using electron-builder, aaaaannndddd.... BOOM. I was instantaneously let down... because electron-builder tried to "be smart" and go to github.com; the same reason the first approach failed. You might think I would have given up here, right?
Well, here's something I always think about then: never give up, always be persistent, and clear your mind if it's foggy. I got this Flatpak to work by thinking about those three things, and getting my eyes red (literally, they were red)... I realized this to full capacity only after struggling so much.... before that I'd always think that was "average advice" and "pointless". But now I see why that really matters (heheh...).
So, then, I switched from electron-builder to electron-packager, which not only was a library electron-builder used, electron-packager was also pretty dumb in the sense that if I used the right flags it would listen to me.
And after using the --electron-zip-dir flag to source to my offline Electron ZIPs in the tarball (and fixing a file path; I spent a while troubleshooting before realizing it was literally just a subdirectory I never mentioned in the environment variable), it worked!
Of course, I had so many failed builds at this point, so Hubert restricted my builds to save Flathub's CI from stress (which makes a TON of sense honestly). After showing him a GitHub Actions workflow I cooked up that worked successfully, he let me build on Flathub's CI again. And after a few other things (such as patching the snapshot code to not reference the home dir instead of the var dir because I swapped from --filesystem access to --persist access for security; forcing XWayland even MORE by manually unsetting WAYLAND_DISPLAY and setting XDG_SESSION_TYPE to x11; and removing an unneeded permission), I got it to work, and here we are.
So now, I'm pretty much at the last legs of this PR. The builds are green, manifest is good and all comments have been addressed. All I have to do now is bide my time and wait, and soon SimpliPlay will be on Flathub! I seriously have no idea how I'm gonna maintain this, but I'm already cooking up a workflow in my head anyway, and things are going pretty well in there :D