So here we are at the 6th week. Here is a list of things I did this week.
- Mitigating Module didn't find error when building the frontend
- Downgrading to Java 8
- Enable deploying O3 from build-distro plugin
- Refactoring setup plugin
Mitigating Module didn't find error when building the frontend
Updates on the frontend have completely broken building O3 frontend. If you try to build the O3 frontend, you will get errors similar to this.
ERROR in ../@openmrs/esm-styleguide/src/modals/index.tsx 19:23-57
Module not found: Error: Can't resolve '@openmrs/esm-extensions' in 'C:\Users\Dale\AppData\Local\npm-cache\_npx\e1faf2b1579efd7d\node_modules\@openmrs\esm-styleguide\src\modals'
@ ../@openmrs/esm-styleguide/src/public.ts 27:16-35
@ ../@openmrs/esm-app-shell/node_modules/@openmrs/esm-framework/src/index.ts 15:13-58
@ consume shared module (default) @openmrs/esm-framework@=5.0.2 (singleton) (fallback: ../@openmrs/esm-app-shell/node_modules/@openmrs/esm-framework/src/index.ts) (eager)
@ ../@openmrs/esm-app-shell/src/index.ts 21:0-33
This error prevented me from effectively testing the OpenMRS SDK.
After conducting further investigation,
I discovered that the error was caused by NPM attempting to build the peerDependencies of the packages.
To mitigate this issue, I found a solution that involves adding the legacy-peer-deps configuration.
By adding the legacy-peer-deps configuration, NPM ignores 'peerDependencies' when building the package tree.
However, it is important to note that this is not considered the best practice.
As a result, we made it optional to enable this configuration.
To enable the legacy-peer-deps configuration, you can use the following command:
mvn openmrs-sdk:setup -DignorePeerDependencies=true
So I created a PR for this which got merged into the master: https://github.com/openmrs/openmrs-sdk/commit/8e9f5cc57f24dc2714f128cf78d3b5569ab34844
Downgrading to Java 8
As part of the recent updates to the OpenMRS SDK, a decision was made to transition from Java 8 to Java 11.
However,
after observing the community's response
and considering the inconvenience caused by changing the Java version on personal machines,
it became evident that this change was not well-received.
Taking community feedback into account, the decision was made to revert back to Java 8.
It looks like altering the Java version on individual machines can be a cumbersome process for a few users.
commit: https://github.com/openmrs/openmrs-sdk/pull/239
Refactoring setup plugin
Enabling setup O3 with the SDK is one of the first things I did. I took the opportunity to review the code changes I made. After careful consideration, I decided to refactor the code to ensure a more consistent and streamlined setup process, aligning it with how we set up O2.
PR: https://github.com/openmrs/openmrs-sdk/pull/224/
Enable deploying O3 from build-distro plugin
The build-distro plugin enables the creation of docker configurations for distributions. While the existing SDK uses embedded templates to generate the necessary docker configurations for O2, I opted for a simpler and more convenient approach for O3.
I created a PR for this: https://github.com/openmrs/openmrs-sdk/pull/234
While the PR is still pending review and merge, I am planning to update the documentation as soon as possible. The updated documentation will provide clear instructions on how to utilize the build-distro plugin for deploying O3 with the OpenMRS SDK.
In addition to this major development, I also worked on addressing minor issues and making trivial changes throughout the week. These smaller tasks contribute to the overall improvement and stability of the OpenMRS SDK.
As for the future, my main goal is to get my pending pull request merged.