Feature: Hot Reloading

[dashcraft]

So, hear me out. With a common host (mcconfig -m -d ), you can already load additional modules via mccrun as .xsa (xs archive format). I assume it bundles all the js files in the mod into the xsa.

A low brow hot reloader might:

1. In a separate process from xs-dev run, watch for file changes
2. Run the mccrun command (or leverage its same mechanism to push to the device) to add/override existing .xsa code
3. Reload the device

If it didn't kill the original process, that'd be great. If it supports over the wire pushing instead of serial, that'd also be great.

A high brow hot reloader might just break apart code into meaningful xsa for singular files, so we only need to push bytecode changes and not entire projects/mods

I know there's a xsdebug port that gets opened and is used to communicate back and forth for xsdebug as well as mccrun (might need to double check they're the same port).

[dashcraft]

As my devs onboard I may set aside dev time to help contribute to this. I've been terrible about contributing, I know I should do better, I'm just so dang busy these days.

[phoddie]

If it didn't kill the original process...

I'm not sure what this means?

[dashcraft]

@phoddie when i'm running the run command it stays running in the console, i assume that's a feature and not a bug (as in it needs to stay connected when i run)

[phoddie]

@dashcraft Correct. When debugging a project, the serial2xsbug tool must be running to provide the bridge from the device's serial port to xsbug.

Would It be enough to create a script that uses xs-dev to achieve your desired functionality, rather than building it into xs-dev? It seems like using a solution like this you would want to customize the behavior and having it outside xs-dev would make that easier.

A high brow hot reloader might just break apart code into meaningful xsa for singular files, so we only need to push bytecode changes and not entire projects/mods

I advise against this. Effectively it means that each module is a separate mod. That is a much bigger and more complex effort for the device to manage, and requires more complex tooling as well.

[dashcraft]

@phoddie absolutely, if my devs can make changes to a HTTP route for instance and the device hot reload without needing to go through the command steps again, that would be perfect. This would be very similar to the current experience when building web server in nodejs with a filewatcher.

[phoddie]

@dashcraft – OK, cool. This helps my understanding. If I can be built, at least initially, without modifications to the Moddable SDK and xs-dev, that seems preferable. That's a great way to learn with minimal impact and complexity. I defer, of course, to @HipsterBrown regarding the scope of xs-dev itself.

This would be very similar to the current experience when building web server in nodejs with a filewatcher.

Good analogy.

[HipsterBrown]

This could be an interesting opportunity to explore the plugin capabilities of xs-dev via the CLI framework it's built upon: https://infinitered.github.io/gluegun/#/tutorial-making-a-plugin

As an opt-in feature, it does seem helpful. 🤔

[phoddie]

@dashcraft – I'm not a very capable Node.js developer, but I stumbled upon the experimental --watch and --watch-path features of Node.js, and they seemed conceptually similar to what you are describing here. Is that the same kind of idea?

One question about this in practice: modern text editors seem to be saving continuously, which means files are saved to disk when they aren't ready to run and may not even compile. Doesn't that create its own problems? Or is there a workflow for using this kind of feature eliminates the concern?

[dashcraft]

@phoddie yes, the watch/watch-path features are very similar, for this i imagine the compile/build step would fail and not push latest changes to device, telling the user that the code failed to compile, maybe even with a helpful warning of where the error is potentially.

For the auto-save feature, it entirely depends on the developer, i always turn off autosave, because linters run on autosave and it adds overhead to the dev process.

But yes, autosaving after a short debounce is a common experience in dev editors.

An example would be the nextjs dev mode, if you push bad changes:

[phoddie]

@dashcraft – very interesting, thanks. At least I think I understand the idea and how it is would be used.