That means there should be almost zero use of any within the repo.
The most important step is ensuring strict: true is enabled in tsconfig.json.
There should be no condition on which that is switched off. This will help
future developers from being able to easily add/change code given the whole system
will have type safety guarantees. This, plus extensive testing, will make our code
more resilient. We should only disable the type-checker/linter when we have no choice,
not because it's easier.
We should treat the master branch with as much respect as possible. This means that our
CI/CD pipeline /.github/workflows should actively enforce the best practices:
- TypeScript for static type checking
- ESLint for code linting
- Prettier for code formatting
- Vitest for unit testing
- Turborepo for builds
It should not be possible to ship code that hasn't gone through the fire. Further, the use of eslint with quite high standards (packages/eslint-config-custom/index.js) is necessary to keep the codebase
code quality high. See CI/CD guide for running commands locally.
We should attempt to be liberal about adding packages if we think it can get re-use from another app in this repo or even outside. This will allow us to expose critical functionality that can make developing further apps easier.
We should attempt to document as we go. That should commonly come in two forms:
- Code comments - When there is code that starts to require domain knowledge to understand, we should be quite liberal about adding in-line code comments to explain variables, functions, decisions, etc.
- Architecture docs - This directory holds the documentation on larger technical decisions and system designs.