This is a monorepo collecting many of the packages used in the Mobile Application Delivery team.
App / Package | Description | Status |
---|---|---|
Chronicles | A storybook-like app for collecting many of the packages in the repo. | |
Components | React Native component library implementing EDS. | |
Skia Draw | Wrappers and utility components for implementing a drawing library in React Native. | |
Maintenance API | Typescript wrapper for the Equinor Maintenance API. | |
TSConfig | Global TSConfig used in our packages. | |
ESLint MAD | Linting rules used throughout MAD development. | |
Navigation | Extension package of react native navigation that adds functionality used in our apps. | |
Insights | Wrapper package providing functionality for adding Azure application insights to your app. | |
Digital Field Worker | Component library for the Digital Field Worker apps. |
This turborepo uses yarn as a package manager. Start by cloning the repository and run
npm install -g yarn
Install dependencies, run
yarn
You can build only the packages you work on, but if you want to build everything to start with, run
yarn build:all
Packages in the repository usually have some common scripts to make development easier. These are
labeled by the following keywords : build
, test
, dev
, and lint
.
The dev
commands wrap package specific needs into a single command for development. Take for
example the MAD Components package. Since any change in its code requires
a build for the MAD Chronicles app to refresh, we define the dev
script in
the components package to build with the watch
flag. A developer working on the component library
does not need to bother with these details, so running
yarn dev:chronicles
yarn dev:components
is all that is required.
This is how development on the packages is set up. With some exceptions, you can run any of these scripts with
yarn {keyword}:{package-alias}
Head into the project root package.json for a full list of all commands.
We use
Trunk-based development
in this repository. Branching is done in and out of the main
branch for each update.
Pull requests into main should as a rule of thumb ALWAYS contain a changeset (see: Changesets). You create these by running
yarn changeset
and follow the promts. This way, changelogs and version bumps are automatically handeled. Also note that we use semantic pull request titles. These are verified automatically during PR linting.
When a piece of code is marked as deprecated, it means that it's not recommended for use and may be removed in a future update. Here are the rules that are followed for deprecated code:
- Marking Deprecated Code: JSDoc comments are used to mark deprecated code. Above the Deprecated code, we add a comment in the following format:
/**
* @deprecated DD.MM.YYYY - This will not be available 6 months after deprecation. Use `alternative` instead.
*/
-
Time Frame: Deprecated code will be kept for at least 6 months after deprecation. This means that if a piece of code is deprecated on 01.01.2021, it will be removed on 01.07.2021 at the earliest.
-
Alternative Solutions: Whenever possible, an alternative solution will be provided in the deprecation comment.
Learn more about the power of Turborepo:
Check out the docs for some of the tools we use throughout the repository:
- Changesets - Versioning
- Jest - Testing
- tsup - Building