I’d like to work on this in the next couple weeks. Not the generator part (sorry @ibacher ) but rather the integration with setup, deploy, and run.
What we have presently is IMO a second SDK, npx openmrs, which is a very good thing and was definitely the right decision. The task now is to integrate that with the maven SDK.
I agree with @mseaton 's proposals. As @ibacher suggests, I think we should implement this by having the maven SDK delegate to the openmrs frontend tool as much as possible.
So I suggest that openmrs-distro.properties should support the following sorts of properties:
# Microfrontends to include, a la microfrontends.json
spa.microfrontends.@openmrs/esm-home-app=next
spa.microfrontends.@openmrs/esm-login-app=1.3.0
# The base application path and SPA path
spa.apiBase=openmrs/
spa.spaBase=openmrs/spa/
# Paths to config files to build in
spa.config=config.json,config-site.json
# Additional import map lines
spa.importmap.config-file=assets/another-config.json
# becomes the line "config-file"="assets/another-config.json"
# Additional assets to bundle with the application
spa.assets=assets
Where we have files config-json, config-site.json, and assets/another-config.json all in the distro folder.
This will build the specified frontend application to frontend/ in the application data directory, both in development and when building the distribution. This will work out of the box with openmrs-module-spa.
I don’t know how the SDK should support builds where the frontend is being served from outside the application data directory. We should figure this out. @mksrom , @mksd ?
I realize this seems like a lot of new stuff in openmrs-distro.properties. Other ideas are welcome. But these are all application build parameters and that seemed like the natural place for them to go.
CC @jdick , @corneliouzbett , @dkayiwa
EDIT: Changed spa.@xyz to spa.microfrontends.@xyz