...

Earlier, we distinguished between the cross-cutting concerns and the elementary UX elements. The latter should either be included in the app shell directly or indirectly via an import map. In any case they are assumed to be always there.

(tbd)

Repositories

One possibility is to utilize a monorepo for combining certain parts:

• openmrs-module-spa (backend module)
• openmrs-esm-spa (app shell incl. openmrs-esm-login, openmrs-esm-home, openmrs-esm-primary-navigation, openmrs-esm-styleguide, openmrs-esm-api, openmrs-esm-module-config, maybe also openmrs-esm-devtools)
• openmrs-esm-patient (patient-registration, patient-chart, decomposed patient-chart-widgets)

The rest remains as single repositories.

(tbd)

Technical Implementation

The foundation that allows a much more flexible and modular system is an extension component ↔ extension slot mechanism. In general, this follows an event listener ↔ event emitter mechanism - just for components.

(tbd)