Gathering detailed insights and metrics for @openmrs/esm-framework
Gathering detailed insights and metrics for @openmrs/esm-framework
Gathering detailed insights and metrics for @openmrs/esm-framework
Gathering detailed insights and metrics for @openmrs/esm-framework
@openmrs/esm-globals
openmrs-esm-globals provides events, variables, and types which are used throughout the rest of openmrs-esm-core.
@openmrs/esm-config
A configuration library for the OpenMRS Single-Spa framework.
@openmrs/esm-translations
O3 Framework module for translation support
@openmrs/esm-feature-flags
A feature flag system for the OpenMRS Single-Spa framework.
The core modules of the OpenMRS 3.0 Frontend system
npm install @openmrs/esm-framework
Typescript
Module System
TypeScript (90.59%)
SCSS (5.67%)
JavaScript (3.05%)
Shell (0.36%)
EJS (0.27%)
Dockerfile (0.06%)
Total Downloads
0
Last Day
0
Last Week
0
Last Month
0
Last Year
0
NOASSERTION License
73 Stars
1,745 Commits
248 Forks
59 Watchers
20 Branches
192 Contributors
Updated on Jul 12, 2025
Latest Version
6.3.0
Package Id
@openmrs/esm-framework@6.3.0
Unpacked Size
10.82 MB
Size
2.49 MB
File Count
170
Published on
May 02, 2025
Cumulative downloads
Total Downloads
Last Day
0%
NaN
Compared to previous day
Last Week
0%
NaN
Compared to previous week
Last Month
0%
NaN
Compared to previous month
Last Year
0%
NaN
Compared to previous year
18
8
5
:wave: New to our project? Be sure to review the OpenMRS 3 Frontend Developer Documentation. You may find the Introduction especially helpful.
Also see the API documentation
for @openmrs/esm-framework
, which is contained in this repository.
Below is the documentation for this repository.
This is a monorepo containing the core packages for the OpenMRS Frontend. These packages handle cross-cutting concerns such as the configuration and extension systems, the core framework, global state management, the styleguide, and more.
This contains tooling and the app shell.
The following common libraries have been developed. They may also be used independently of the app shell.
routes.json
files in O3All libraries are aggregated in the @openmrs/esm-framework
package:
A set of frontend modules provide the core technical functionality of the application.
To set up the repository for development, run the following commands:
1yarn 2yarn setup
To build all packages in the repository, run the following command:
1yarn build
Verification of the existing packages can also be done in one step using yarn
:
1yarn verify
1yarn run:shell
run:shell
will run the latest version of the shell and the framework only.
apps
1yarn run:omrs develop --sources packages/apps/<app folder>
This will allow you to develop the app similar to the experience of developing other apps.
1cd packages/tooling/openmrs 2yarn build 3./dist/cli.js
To run tests for all packages, run:
1yarn turbo run test
To run tests in watch
mode, run:
1yarn turbo run test:watch
To run tests for a specific package, pass the package name to the --filter
flag. For example:
1yarn turbo run test --filter="@openmrs/esm-styleguide"
To run a specific test file, run:
1yarn turbo run test -- login
The above command will only run tests in the file or files that match the provided string.
You can also run the matching tests from above in watch mode by running:
1yarn turbo run test:watch -- login.test
To generate a coverage
report, run:
1yarn turbo run coverage
By default, turbo
will cache test runs. This means that re-running tests without changing any of the related files will return the cached logs from the last run. To bypass the cache, run tests with the force
flag, as follows:
1yarn turbo run test --force
To run E2E tests locally, follow these steps:
Begin by spinning up a development server for the frontend module that you want to test. Ensure the server is running before proceeding.
Copy the example environment variables into a new .env file by running the following command:
1cp example.env .env
Run the tests with the following command:
1yarn test-e2e --ui --headed
Read the e2e testing guide to learn more about End-to-End tests.
You probably want to try out your changes to a framework library in a frontend module. Unfortunately, getting a working development environment for this is very finicky. No one technique works for all frontend modules all the time.
Note that even though frontend modules import from @openmrs/esm-framework
, the package you need to link is the sub-library; for example, if you are trying to test changes in packages/framework/esm-api
, you will need to link that sub-library.
If you're unsure whether your version of a core package is running, add a console.log
at the top level of a file you're working on.
Here are the tools at your disposal for trying to get this to work:
This should be the first thing you try. To link the styleguide, for example, you would use
1yarn link ../path/to/openmrs-esm-core/packages/framework/esm-styleguide
This will add a line to the "resolutions" section of the package.json
file which uses the portal:
protocol.
The other protocol is link:
. If you need to make changes to the esm-framework
package, you will need to link
it in as well. However, this does not work as a portal created with the yarn link
command. Rather you will
want to manually add the line to the resolutions
field in the package.json
file:
1"resolutions": { 2 "@openmrs/esm-framework": "link:../path/to/openmrs-esm-core/packages/framework/esm-framework" 3}
Sometimes, the build tooling will simply not work with yarn link
. In this case, you will need to use yalc
.
Install yalc
on your computer with:
1npm install -g yalc
Then, link the repository you are working on. For esm-api
, for example, run
1# In this repository 2cd packages/framework/esm-api 3yalc publish 4cd ../../../openmrs-esm-patient-chart # for example 5yalc link @openmrs/esm-api
In order for patient-chart to receive further updates you make to esm-api, you will need to run yalc push
in the esm-api directory and yalc update
in the patient-chart directory.
This satisfies the build tooling, but we must do one more step to get the frontend to load these dependencies at runtime.
Here, there are two options:
In order to get your local version of the core packages to be served in your local dev server, you will need to link the tooling as well.
yarn link /path/to/esm-core/packages/tooling/openmrs
.
You can try using yalc
for this as well, if yarn link
doesn't work. Or manually creating a link:
resolution in package.json
.
In packages/shell/esm-app-shell, run yarn build:development --watch
to ensure that the built app shell is updated with your changes and available to the patient chart.
Then run your patient chart dev server as usual, with yarn start
.
In esm-core
, start the app shell with yarn run:shell
. Then, in the patient chart repository, cd
into whatever packages you are working on and run yarn serve
from there. Then use the import map override tool in the browser to tell the frontend to load your local patient chart packages.
Please note that any of these techniques will modify the package.json
file. These changes must be undone before creating
your PR. If you used yarn link
, you can undo these changes by running yarn unlink --all
in the patient chart repo.
We use Yarn workspaces to handle versioning in this monorepo.
To increment the version, run the following command:
1yarn release [version]
Where version corresponds to:
patch
for bug fixes e.g. 3.2.0
→ 3.2.1
minor
for new features that are backwards-compatible e.g 3.2.0
→ 3.3.0
major
for breaking changes e.g. 3.2.0
→ 4.0.0
Note that this command will not create a new tag, nor publish the packages. After running it, make a PR or merge to main
with the resulting changeset. Note that the release commit message must resemble (chore) Release vx.x.x
where x.x.x
is the new version number prefixed with v
.
This is because we don't want to trigger a pre-release build when effecting a version bump.
Once the version bump commit is merged, go to GitHub and draft a new release.
The tag should be prefixed with v
(e.g., v3.2.1
), while the release title should just be the version number (e.g., 3.2.1
). The creation of the GitHub release will cause GitHub Actions to publish the packages, completing the release process.
Don't run
npm publish
,yarn publish
, orlerna publish
. Use the above process.
When releasing a new major version (e.g., moving from v6 to v7), you must:
@openmrs/
packages in every package that depends on them6.x
to 7.x
)Example:
1// Before (during v6) 2"peerDependencies": { 3 "@openmrs/esm-config": "6.x", 4 "@openmrs/esm-utils": "6.x" 5} 6 7// After (for v7) 8"peerDependencies": { 9 "@openmrs/esm-config": "7.x", 10 "@openmrs/esm-utils": "7.x" 11}
This ensures that all packages use compatible versions and breaking changes are properly tracked.
For documentation about our design patterns, please visit our design system documentation website.
Be sure to update the Playwright version in the Bamboo Playwright Docker image whenever making version changes. Also, ensure you specify fixed (pinned) versions of Playwright in the package.json file to maintain consistency between the Playwright version used in the Docker image for Bamboo test execution and the version used in the codebase.
No vulnerabilities found.
Reason
30 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 10
Reason
no dangerous workflow patterns detected
Reason
no binaries found in the repo
Reason
packaging workflow detected
Details
Reason
SAST tool is run on all commits
Details
Reason
Found 27/30 approved changesets -- score normalized to 9
Reason
license file detected
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
project is not fuzzed
Details
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
24 existing vulnerabilities detected
Details
Score
Last Scanned on 2025-07-07
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More