Consider adding Hot-Reloading

[davesmith00000]

@megri has made an interesting gist showing how you might use the electron-reloader module with Indigo.

https://gist.github.com/megri/9b82e3fc0cbf9b87f1c36ef477129300

Two things:

1. We could bake a solution like that into the plugin, and provide a new flag in IndigoOptions to enabled / disable hot reloading.
2. We could also look at making a SubSystem that works in a similar way to Tyrian's HotReloading functionality, in order to load / restore game state to local storage. That way if the browser or electron reloader kicked in, the game would carry on where you left off.

[megri]

Some things I learned while playing with this thing:

• T.worker is useful for tracking things like file changes between compilations, but be cautious of conflicting life cycle management—in my example both mill and electron-reloader tries to manage the Electron process which leads to orphaned processes;
• Trust the mill cache mechanism; make everything that should influence the outcome of a build a Target. Use T.source for paths that should be watched, like app-root;
• Bootstrapping node-projects is simple and self-contained with os.proc("npm", "install", …).call(cwd = T.dest) but symlinks needs to be considered when copying the node_modules directory around.

[megri]

I believe the best UX would be attained by replacing electron-reloader with something more tailored to Indigo and use a worker to steer the updates uni-directionally.

[megri]

I put together a POC where mill drives the reloading all by itself and it's less glitchy than using electron-reloader: At the moment it triggers a win.reload() when game-code changes and recreates the process entirely when index.js is updated.

The catch is that it does this by pushing data to the Electron-process through stdin, which as far as I understand does not work for Windows. Now looking for a platform-independent method of doing IPC.