Autoreload + autoexecute

[ashryanbeats]

Hi all, this is a very speculative exploration, but I thought it might be worth doing in the open, since I'd wager most of us have wished plugins would autoreload (any maybe even re-run) during development.

I've made a branch here, which for now, is meant to get feedback on both the idea and the approach.

It's definitely not fully fleshed out, and comes with limitations at the moment, including:

1. Doesn't support Windows yet
2. Probably doesn't support panels (currently in prerelease)
3. Various rough edges (still an early idea)

https://github.com/AdobeXD/xdpm/tree/osa

Usage:

$ xdpm watch -r -u "Create Rectangle" -x "Create Rectangle"

Where:
-r = autoreload
-u [command name] = autoundo, if last action matches the command name passed
-x [command name] = autoexecute

[pklaschka]

I think one thing to consider in an implementation of this is how to handle the auto-execute part when nothing can get executed. When I develop a plugin (due to the way my IDE is setup), plugins get saved (and therefore "deployed" by XDPM far more often than I actually want my plugin to execute. Also, some consideration about what happens when the plugin is already running (and therefore blocking further execution) might be wise.

All in all, I think that this is a great idea, but things like AppleScript (and – if there's any Windows-alternative for that – other automation scripting languages) might cause more trouble than they're worth. They might make cross-platform-compatibility much more complicated to maintain and still have a bunch of problems coming with them.

In my opinion, it could make more sense if (as part of the developer tools integration that's already part of the roadmap) XD provided some sort of functionality to do this programmatically (e.g., via a socket server).

Having things like

• executing a plugin
• reading console output
• canceling execution of a plugin
• reloading plugins
• loading a plugin's "testing" XD file

as an accessible API (e.g., as a socket server or local REST API) would not only allow for a smooth integration of those features into XDPM (in a cross-platform and much more "controllable" manner) but would also open up XD for things like TDD for plugins and much more.

Therefore, while I think that it's a great idea, I think that it should get executed "well" (which can only be the case when XD opens up those possibilities) rather than soon. Doing it with something like AppleScript (or some other manner of automation) seems hacky and (to be honest) sounds like bringing more harm than what it's worth. As much as I hate to say this: since xdpm is a professional tool which I might rely on as a plugin developer (especially if I'm doing it for a living), introducing such functionality in a way that feels "hacky" and might cause problems due to the lack of control that's possible with the current state of XD doesn't allow me to be confident in xdpm, which might not be the best of ideas. Therefore, while I love the idea, I can't honestly say I like the idea of implementing it now since there simply isn't the level of control yet to implement this in a good and "frustration-free" way.