sindresorhus
Switch to Electron Forge
[!IMPORTANT] This is currently WIP and flagged as draft PR, so (hopefully) maintainers won't have to take their time on reviewing something and suggesting the changes I'll (possibly) do eventually in the future. When working on this, I was uncertain whenever Caprine maintainers are even considering this change to be merged at all and if they are against using Forge overall in their project or not.
[!CAUTION] While I can test how this works on Windows and Linux, the policy of Apple (around running macOS on non-Apple hardware) makes me effectively unable to test how this on macOS. I might also be unable to write a correct signing configuration for it, leaving this to be worked on by somebody else.
Description
This is an initial work on moving Caprine from electron-builder to Electron Forge.
Reasoning
✅️ Improvements
electron-builder is awesome when it comes to the list of kinds of the packages it officially supports. However, it isn't thought well of building the packages on all platforms and architectures it support the packages for, meaning that some users wanting to self-package Caprine has to use VM and/or emulation, just to be able to package it with electron-builder successfully (this is mostly the case for the ARM users, both Linux and Windows).
Moreover, Electron Forge is now considered as an official toolkit for packaging Electron apps and is maintained by Electron developers themselves. Also, the code structure of Forge and the API it provides makes it possible to easily extend it by third-party components, allowing for more decentralised development.
❌️ Limitations
While Forge's being much more extensible alternative to electron-builder, it still doesn't provide the support for building all of the kinds of the packages that electron-builder can produce. For Caprine this means currently, if switch to Forge would be made now, there would be a need to drop the NSIS Windows installer for the project and switch to Squirrel. As of the Squirrel, I think right now it might also be problematic to support the auto-updates on it if targeting multi-arch support with this project (i.e. by producing both 32-bit and ARM installers), since produced files by it have conflicting names.
