The RPCh monorepo contains the main components required to bring RPCh to life.
We have four main project folders:
- configs: contains internal configurations, not published
- packages: contains libraries that are used internally, and could be used externally, published
- apps: contains services which are run centrally by the RPCh org
- devkit: contains developer tools and sandbox material
- Install nodejs
v18 - Download dependencies with
yarn - Build everything with
yarn build
Checkout Sandbox which lets you try RPCh locally via docker.
- unit-tests: you are required to run a postgres instance locally in order to run the unit tests
the connection string must look like
postgresql://postgres:postgres@127.0.0.1:5432 - coverage: currently we can generate coverage reports for each project, but we do not have a threshold set in which we would fail our CI
- dependency check: we currently use
check-dependency-version-consistencyto ensure consistency between the dependency version, future plan is to usedepcheckfor every project to ensure all libraries are correctly added perpackage.json
This project aims to use Changesets for versioning. We will gradually add changesets for new releases/tags, so that given some time we will have every app/package covered.
This monorepo will use the usual tagging scheme for monorepos: Tags are usually only created prior to releases. See Deployment section.
org/appname-vX.X.X
org # organization name, usually @rpch
appname # application or package name to be released with that tag
- # slash separator
v # single letter 'v'
X.X.X # Semver versioning for that app or package
Deployment works automated.
For staging, pull requests are built and merges/pushes to the main branch will also trigger builds.
For production, this works a little bit different.
Whenever a new tags is updated (usually alongside corresponding changeset changes) on main the automation will check
- if it can build new application container images
- if it can publish new npm packages