Mike, I agree with you regarding separating things into (1) and (2). I agree that (2) would allow an implementer to follow the common OpenMRS pathway for making available MF assets. And I think the module as is does this ok though I’d let @bistenes confirm this.
I do think the intention is to find a seamless way of using more contemporary approaches to achieve both (1) and (2). This should be clearer once @florianrappl has the POC to demonstrate.
Yeah, I agree with what @mseaton and @jdick are saying, that it could be a good mechanism for making deployment easy. It could certainly do that better than it does at present, even.
However I’m definitely open to alternatives that @florianrappl might propose, provided they’re well fleshed out.
FYI @sharif - we clarified this topic at the TAC meeting on Friday last week. Here’s what we agreed:
Decision: Remove the SPA module from the RefApp 2.11.0 release.
Why:
Whether or not we use a module-approach to enable implementations to experiment with microfrontends is still an in-flux-decision. On Thursday at the MFE Squad weekly demo, Florian demo’d an early prototype that supports an alternative way for frontends to be deployed and related to each other. Summary: This approach ties core parts of the framework together; and implementers can download whole MFE in more logical way. We still need to define best practice for working w/ frontends and being able to start using them, instead of via modules that plug in. Idea is loading in OMRS frontends w/ npx; so you’d have the frontend running and be able to pop in your own modules easily. (Goal is lower-barrier way for people to load and start experimenting with Frontends.)
We can always add the module to the Add-Ons directory if we end up using the module-based approach in the near future; however, right now there isn’t a plan to maintain the SPA module, so it doesn’t make sense to add it to the Add-Ons directory at the moment until the plan is more clear (so definitely not to the RefApp bundle).
That module is not yet vetted enough to know it won’t cause surprising concerns elsewhere (though this is probably unlikely)
We need to reduce the scope of this release to allow quality testing
