We use pnpm built-in support to manage our monorepository.
It is highly recommended to be working with VSCode, an IDE that does not need to be presented. Internally, we use a set of code extensions enabling a minimum of code standardization, making the life of many developers more enjoyable. Those extensions are given in .vscode/extensions.json, and can be downloaded directly via the VSCode extension store. This goes hand and hand with properly configured VSCode workspace settings, available in .vscode/settings.json.
To use this repository, you need to have the following tools installed:
- Node.js (v16.17.1)
- pnpm (v7.16.0)
- Makefile
- Docker (v20.10.8)
- Docker Compose (v1.29.2)
To install all dependencies, run:
make install
If you want to hard install all dependencies, you can run:
make hard-install
After install all dependencies, we need to start the applications.
First run :
make start-database
Then we need to initialize the database, you can do it running:
make init-database
Now you are ready !
As a developer, to work on the project on everyday, you will certainly want to start the applications seperately in debug mode :
Run make start-client and make start-server in two differents terminals.
You can also see logs of database by running make start-database.
If you want to just launch all in quiet mode, run :
make start-all
Common workspace is used to share code between client <> server.
We use Husky to ease git hooks.
We follow the Conventional Commits specs for our commit message and this is check on commit-msg.
We use the same prefixes for branch names and this is also checked on branch-naming.
We also follow the prettier specs for code formatting and this is checked on pre-commit.
Here is the list of commit types and branch prefixes you can chose from :
| Commit Type | Title | Description |
|---|---|---|
feat |
✨ Features | A new feature |
fix |
🐛 Bug Fixes | A bug Fix |
docs |
📚 Documentation | Documentation only changes |
style |
💎 Styles | Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) |
refactor |
📦 Code Refactoring | A code change that neither fixes a bug nor adds a feature |
perf |
🚀 Performance Improvements | A code change that improves performance |
test |
🚨 Tests | Adding missing tests or correcting existing tests |
build |
🛠 Builds | Changes that affect the build system or external dependencies (example scopes: next, webpack, pnpm) |
ci |
⚙️ Continuous Integrations | Changes to our CI configuration files and scripts |
chore |
♻️ Chores | Other changes that don't modify src or test files |
revert |
🗑 Reverts | Reverts a previous commit |
See the regex validating the branch naming here.
Structure :
<user>/<type>/<short-description>
Examples :
rv/feat/signup-page
jk/ci/github-actions-setup
nc/fix/calendar-input-focus-not-working
Structure :
<type>(optional scope): <description>
Examples :
ci(front): setup storybook tests
fix: send cors headers
feat(groups): add comment section
To maintain some minimal standards within our codebase, we rely on prettier that is configured through .prettierrc. We use .prettierignore to avoid conflicts with some configuration files that would otherwise be broken by using prettier. Make sure prettier is correctly used in VSCode by installing the VSCode extension.
We did set up a .nvmrc file to allow developers to quickly change and use the right node version. See nvm package and deeper shell integration.