Given the size of the plugin nowadays, this would be a pretty nice thing to support, since making any new releases at this point consists, more than not, of checking a bunch of common and uncommon actions to see if they break things.
As it is, the plugin is heavily coupled to both GMEdit, Node, and the DOM. I'd love to see some future where the various components can be separated out, such that UI responsibilities, plugin state, and the actual build capabilities are less interconnected.
At the least, I'd like to test the latter of the three, as it is both the least dependent on the others, and most core to the plugin's functionality. This would also make things simpler for working on GMRT support.
Whether I actually do this is pretty iffy, given the time investment required, since Constructor doesn't really have a very large userbase, to my knowledge at least, but regardless, I'm throwing this out here as something for the future to think about.
Checklist
Given the size of the plugin nowadays, this would be a pretty nice thing to support, since making any new releases at this point consists, more than not, of checking a bunch of common and uncommon actions to see if they break things.
As it is, the plugin is heavily coupled to both GMEdit, Node, and the DOM. I'd love to see some future where the various components can be separated out, such that UI responsibilities, plugin state, and the actual build capabilities are less interconnected.
At the least, I'd like to test the latter of the three, as it is both the least dependent on the others, and most core to the plugin's functionality. This would also make things simpler for working on GMRT support.
Whether I actually do this is pretty iffy, given the time investment required, since Constructor doesn't really have a very large userbase, to my knowledge at least, but regardless, I'm throwing this out here as something for the future to think about.
Checklist
node:test, since the majority of the codebase is operable withoutwindow.