@mseaton and myself dominated the conversation on TAC today, but I think we made some good progress on packaging conventions.
“A package is a definition of what artifacts are that make it up” -Mike Seaton
- What string format convention do we use when referring to an asset (ESM, omod, metadata, etc.)?
- Plan: Take existing conventions and document them (e.g., what we’re doing in distro.properties)
- Which versioning format do we use? Are there libraries for this?
- Prefer to adopt a well-established convention instead of continuing to use our own custom syntax
- Plan: Look for library to convert between npm <=> maven
- For modules, do we organize by asset type (omod, esm) or build tool (maven, npm)?
- Plan: Defer for now
- Mentally walking through a simple build process. What are the steps we expect to happen?
- Plan: Add ability to refer to config or metadata by URL in properties file
- Do frontend modules declare what backend modules they depend upon?
- Plan: Investigate how we could declare backend dependencies in packages.json (e.g., declaring an ESM depends on a minimum version of OpenMRS FHIR2 or REST-WS module).
- @mseaton would like to have
distro.propertiesthat refers only to versioned artifacts (e.g., in maven). So, we instead of listing all ESMs in this file; rather, we would refer to a pre-built frontend artifact that contains the built artifact.- This may be a fundamental difference between distro & package definitions: distro refers to built artifacts, while a package definition will need to refer to ESM source.
- PIH uses a pom.xml like this to generate a frontend artifact (turning a definition like this into a maven artifact like this), so changes to non-frontend parts of the distro (e.g., bumping an omod version) doesn’t require re-building the frontend.
- Plan: Look into either grouping or separating list of individual frontend components in order to support isolation of frontend definition such that frontend build only happens when needed and we can support generation of a frontend artifact.