We follow the airbnb style for naming.
We use prettier to format code. Run yarn prettier --check . to show formatting problems or yarn prettier --write . to fix them.
We use typescript-eslint for TypeScript linting. Run yarn lint to show linting problems.
- Preferr arrow functions
- Use functional components
Tests should always be positioned in a __tests__ directory on the same level as the file which is tested.
├── __tests__
│ └── Caption.spec.js
└── Caption.js
See this guide for a general reference on how to write
good commit messages.
Commit messages should have the following schema:
<Issue key>: Your commit message, e.g. LUN-612: Add commit message documentation
The same applies for PR names. Branch names should also start with <Issue key>-Prefix
To merge a pull request, it has to match our Definition of Done. It includes among others:
- All checks (linting, unit and e2e tests, ...) have to pass.
- No changes are requested.
- Two approvals are needed.
- New and changed functionality should be tested sufficiently, both manual and by writing unit tests.
Creating a pull request from a fork prevents checks from the CI. It is a good way to make contact though.
Versions consist of a version name and a version code.
The following schema 
PATCH is a counter for the number of releases in the corresponding month starting with 0.
Examples:
- First versions of 2020:
2020.1.0,2020.1.1,2020.1.2. - First version of February 2020:
2020.2.0.
An additional consecutive version code is used for unique identification in the app stores.
The version code is incremented for every build uploaded to the stores.
The first version code was 100000.
tbd.