By engaging and collaborating with our community we can deliver a more robust product that bridges cultural differences and empowers decision making within health systems worldwide.
For contributor's code of conduct - see the code-of-conduct.md published in the repo.
This is a mono-repo
It is set up using yarn workspaces
, meaning any command you would normally run inside a package can
be run from the root directory using yarn workspace @tupaia/package-name command
, e.g.
yarn workspace @tupaia/central-server start-dev
The easiest way to open the packages in vscode is to double click 'tupaia-packages.code-workspace'. This opens all packages as roots in the workspace, and means linting etc. will work correctly.
The Tupaia mono-repo is comprised for 3 types of packages:
- Platform interfaces (Frontend React applications that the user interacts with)
- Servers
- Orchestration servers (dedicated backend applications for each platform interface)
- Micro servers (applications which are used by the orchestration servers to perform common system functions)
- Libraries (various utility and common libraries that are used throughout the mono-repo)
While each package type has their own structure, there are a few common standards:
<package>/package.json
- package definition<package>/src/
- contains source code<package>/.env.example
- file showing what environment variables are required by the package<package>/.env
- environment variables used by package (ignored in git)<package>/src/__tests__/
- contains unit tests
- Tupaia (for legacy reasons referred to as web-frontend)
- Tupaia Web (New version of web-frontend)
- Tupaia Datatrak Web
- Admin Panel
- LESMIS
- PSSS
- Meditrak
- web-config-server (Tupaia's orchestration server, referred to as web-config-server for legacy reasons)
- admin-panel-server
- lesmis-server
- psss-server
- meditrak-app-server
Server packages can be built by running yarn workspace @tupaia/package-name build
.
Server packages can then be started by running yarn workspace @tupaia/package-name start
.
All servers are NodeJS express applications, and the packages follow the same basic structure:
<package>/examples.http
- example queries showing the server interface<package>/src/index.ts
- server entrypoint<package>/src/app/createApp.ts
- express router definition<package>/src/routes/
- route definitions
- access-policy
- aggregator
- api-client
- auth
- data-api
- data-broker
- data-lake-api
- database
- devops
- dhis-api
- e2e
- expression-parser
- indicators
- ui-components
- ui-chart-components
- ui-map-components
- server-boilerplate
- superset-api
- ui-components
- utils
- tsutils
- types
- weather-api
Most packages will require a .env file. .env.example
files indicate the required variables per package.
π BES internal: Adding .env files
π BES internal: Tupaia monorepo setup - steps 4 and 5
We use yarn workspaces to manage our packages, which allows us to run yarn
once at the project
root, and it will install dependencies everywhere.
We use codeship for the CI/CD
π BES internal: CI/CD using Codeship
Most of the packages support the following scripts for testing:
yarn test
yarn test:coverage # also displays code coverage
We use a combination of ESlint configs to detect quality and formatting issues in code:
- @beyondessential/eslint-config-js for JavaScript packages
- @beyondessential/eslint-config-ts for TypeScript packages
- @beyondessential/eslint-config-jest for packages using
Jest
The config for this repository is defined in .eslintrc
under the root folder. Additional rules/overrides per package are specified in this file.
In order to automatically format code in VSCode according to our style guide:
- Install Prettier for VSCode
- Enable the
Editor: Format on Save
setting - Your files will now be formatted automatically when you save them