feat: support new upgrade execution for modules #3412
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implements bitfocus/companion-module-base#118
This has turned out to be a more complex state machine than I initially expected, so I am wondering if this should be held back for 4.1 (it could still be reverted in the module lib, so that the other changes can be released)
This api change is done so that how the options are stored can be different from how they are used, without needing modules to be the ones doing the parsing.
This is a precursor to #2345, which I expect will build on this by further by changing the structure of the options object that companion and upgrade scripts use, but not for action/feedback execution or subscribe/unsubscribe calls.
At this stage, that means we can pre-parse variables in textinput fields (only those with the
useVariables
flag set for now) before passing the objects off to the modules.This should be non-breaking for modules, and only those using the updated base lib will hit the new flows, so any bugs found will have limited impact.
TODO