Rethink about the runtime process model and electron

[Yukaii]

I have some difficulties starting the application shipping process around commit fb29964.

Initially, I started the runtime in electron's utility process and struggled with packager bundling 2fcb790. Eventually, I found it too troublesome to eval/load the extension module and its dependencies inside the electron main process, so I decided to manage the Node.js binary on the user's computer and run the runtime with that nodejs runtime.

Regarding the shipping of the runtime, currently I use esbuild to build another single file cjs module of blast-runtime. I have two options:

• Use that downloaded node binary's npm to install @blastlauncher/runtime with ~/.blast/extensions prefix, just like other blast-extensions. The version can be explicitly found in ~/.blast/extensions/package.json, and version pinning and upgrading can also be easily done.
• Ship the runtime module as electron assets. We can bundle it with electron-forge's webpack, and there's no need to handle some spawn process magic. But it needs to be upgraded with the electron app itself.

About the compatibility between the runtime and frontend, it's another story.

Tasks

• Update the @blastlauncher/runtime package to include minimum runtime dependencies. All deps should be bundled with esbuild.
• Publish a new version of runtime. Use it along and pack with electron-client module webpack
• Implement a node binary manager module in @blastlauncher/utils (We can search for an existing solution first).
• Integrate the node binary manager in the electron-client.
• Implement a runtime process manager in the electron-client.

[Yukaii]

• https://stackoverflow.com/questions/62405815/loading-nodejs-module-at-runtime-in-electron-app
• https://github.com/davideicardi/live-plugin-manager

[Yukaii]

• Bundle blast-runtime/run.cjs along with electron app

https://github.com/ganeshrvel/tutorial-electron-bundle-binaries/