1. Developer "A" has a working WAB app, published to AGOL organization account and works perfectly.
2. Developer "B" takes over WAB app originally built by Developer "A" and has some requested changes to apply to it.
Developer "B" acquires the .zip file of the currently deployed WAB, attempts to "Import" it in WAB Developer installed locally and gets error: "Parse app failed".
Just how does Developer "B" import that WAB to make changes via WAB Developer (local install) and redeploy to AGOL?
The times I have seen this happen is when Dev A has custom widget A version 1.2 and Dev B has custom widget A version 1.3 or vice versa and you try and import it causes a parse fail. So check that both have the same versions of the custom widgets.
So would you agree that it's a good idea to create a central repository of these custom widgets within our network/file system and have each developer use these widgets in their implementations?
It will require some additional effort to be sure we have all desired widgets, as well as create a new process for a developer to have to request a widget, but this way we'd have greater control over versions between developers.
I would say that it would be just as easy to implement a workflow that Dev A if using custom widgets in their app informs Dev B of what versions they are using before Dev B imports. But workflow is a matter of preference.
We have Developer A, B, C, D and E --- at any time each developer would need to be able to jump in and take part in an implementation that any other developer is working on. That's a pretty extreme case/requirement, but is the kind of capability we'd probably want to have.
Also: would any widget re-configuration need to occur on any existing WAB after importing an updated widget? (I can quickly test that, just assuming it would not be a requirement).
Thanks again for your input Robert! Much appreciated.
not if there was not any new config parameters added to the widgets config file and still if the widget is developed well then the new parameters will have default supplied in the code and the parameter not being present in the config will not cause the widget to error.