2022-02-14 TAC: Continuing the discussion on OpenMRS Packaging conventions

Agenda for this Monday (14 February): Continuing the discussion on OpenMRS Packaging conventions

We’ll continue reviewing our Draft schema for OpenMRS Packages and walk through an example.

From last week, we decided:

  • To use our existing conventions for referring to assets (ESM, omod, metadata, etc.)
  • To look for a library to convert semver between npm versioning & maven version numbering
  • 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.


  • 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

/cc @ibacher @mksd @eudson @mayanja @mseaton @mogoodrich @bistenes @jdick @ssmusoke @grace @raff & please CC others you think would be able to help us in creating initial conventions for packaging.


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.

(FYI @burke @mseaton )

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.

That’s right. I was just using this to point out how the information is currently captured.