Defer decisions on organizing content within a package until we’ve got the references (what goes into a package and how we refer to it) worked out
Add ability to refer to config or metadata by URL into our properties file
Investigate how frontend code (e.g. ESMs) could declare backend dependencies (e.g., “this frontend module depends on REST-WS 2.32.0+ and fhir2 1.3.0+”)
Decided a distinguishing factor between distribution & package properties is distro definitions refer to built/packaged (i.e., maven) artifacts, while packages may refer to source or content outside of maven artifacts.
Agenda:
Mentally walking through adding a “package” with an ESM, module, and concept to OMRS 3. What are the steps we expect to happen?
Where: om.rs/zoomtac
When: Monday at 3pm UTC / 7am PST / 10am EST / 4pm CEST / 6pm EAT / 8:30pm IST
Cross posting a follow up comment from @bistenes & @ibacher on the 3.x slack channel:
@bistenes is thinking it would be reasonable for ESMs to come with a file (e.g. YAML?) that contains the backend dependencies, so that these could easily be ready by non-JS tooling.
@ibacher reckons that part seems straight-forward enough to do. We also have (not that straight-forward but manageable) a means for extracting dependencies from OMODs.
Do we need a separate file? Couldn’t we define the dependencies alongside the other dependencies in the package.json (e.g., under an “openmrs” key)? That way, the ESM could more easily access the info if we wanted to use it in the future (e.g., for an automated dependency check).
We already have an automated dependency check for backend modules, though I think it just produces a warning. Almost all (if not all) ESMs declare their backend dependencies already like this.
I don’t quite know what the LOE difference is between creating a new file and modifying things to derive that data from the package.json, but we should probably go with whatever is easiest. I suppose the advantage of using package.json is that we can also ensure that all peer dependencies are provided by the distro configuration.
@ibacher thanks - to be clear, the existing code will only show a warning to someone who is actively running a server, once deployed. There is no way to determine at build time or pre-deployment whether an esm is compatible with a given OpenMRS server, correct? That’s what we are trying to design out here.
If we put the dependencies in package.json (e.g., openmrs.dependencies), then both the frontend app and SDK (or other tooling such as CI builds) could easily find it… and we’d be adopting/extending the existing convention for declaring dependencies for JavaScript projects.