- πΊ What is this API ?
- π Available roles
- π¨ Installation
- π Build
- π³ Docker
- π― Tests
- πΏ Env variables
- βοΈ Code analysis and consistency
- π Releases & Changelog
- π GitHub Actions
- β¨ Misc commands
- Β©οΈ License
- β€οΈ Contributors
Werewolves Assistant API provides over HTTP requests a way of manage Werewolves games to help the game master.
This is the next version of the deprecated Werewolves Assistant API.
This API is used by the Werewolves Assistant Web App.
π€ Want to know more about this awesome project ? Check out the dedicated about page.
30 different official roles are available to play :
To install this project, you will need to have on your machine :
We recommend to use the node version specified in the .nvmrc
file.
If you don't have pnpm
installed, you can still use npm
for all commands below, but we recommend to use pnpm
for faster and more reliable installs.
Then, run the following commands :
# Install dependencies and Husky hooks
pnpm install
# Run the app in dev mode
pnpm run start:dev
The above command will start the app in development mode and watch for changes on local.
You can also run the app in development mode with Docker, more information in the Docker section.
In order to build the app for production, run the following command :
# Build the app
pnpm run build
# Run the app in production mode
pnpm run start:prod
You can also run the app in production mode with Docker, more information in the Docker section.
This app is Docker ready !
The Dockerfile is available at the root of the project. It uses a multi-stage build to optimize the image size and distroless image to reduce the attack surface.
To run the app in development mode with Docker, multiple commands are available :
# Run the app in development mode with Docker
pnpm run docker:dev:start
# Stop the app in development mode with Docker
pnpm run docker:dev:stop
# Reset the app in development mode with Docker (stop, remove image, containers and volumes, then start)
pnpm run docker:dev:reset
When starting the app in development mode with Docker, a container for the API and a container for the MongoDB database are created.
Docker compose will use the development
step of the Dockerfile to build the image.
For more information, please check the docker-compose.yml file.
To run the app in production mode with Docker, multiple commands are available :
# Run the app in production mode with Docker
pnpm run docker:production:start
# Stop the app in production mode with Docker
pnpm run docker:production:stop
# Reset the app in production mode with Docker (stop, remove image, containers and volumes, then start)
pnpm run docker:production:reset
When starting the app in production mode with Docker, a container for the API and a container for the MongoDB database are created.
Docker compose will use the production
step of the Dockerfile to build the image.
For more information, please check the docker-compose.yml file.
To run the tests available in this project thanks to Docker, multiple commands are available :
# Deploy test containers (4 databases are created to parallelize tests)
pnpm run docker:test:start
# Stop test containers
pnpm run docker:test:stop
# Reset test containers (stop, remove image, containers and volumes, then start)
pnpm run docker:test:reset
For more information, please check the docker-compose.yml file.
Click on the badge below π to see the reports.
You can also check the mutation testing report.
Before testing, you must follow the installation steps.
Then, run one of the following commands :
# Assure you started test Docker containers (4 databases are created to parallelize tests)
pnpm run docker:test:start
# Run unit tests with coverage
pnpm run test:unit:cov
# Run e2e tests with coverage
pnpm run test:e2e:cov
# Run both unit and e2e tests with coverage
pnpm run test:cov
# Run both unit and e2e tests only on staged files (run on pre-commit)
pnpm run test:staged
# Run acceptance tests
pnpm run test:cucumber
# Run acceptance tests and publish the report
pnpm run test:cucumber:publish
# Run mutant tests with coverage
pnpm run test:stryker
# Run mutant tests with coverage from scratch (without using the incremental file)
pnpm run test:stryker:force
Environnement files are available in the env directory.
You can create a .env
file in this directory to override the default values when starting the API locally with pnpm run start
command.
Environment variables are :
Name | Description | Required | Default value | Limitations |
---|---|---|---|---|
HOST |
Host on which the API will be available | β | 127.0.0.1 |
If set, can't be empty string |
PORT |
Port on which the API will be available | β | 8080 |
If set, must be a number between 0 and 65535 |
ENVIRONNEMENT |
Environment in which the API will run | β | β | Must be development , production or test |
DATABASE_HOST |
MongoDB database host URL | β | β | Can't be empty string |
DATABASE_PORT |
MongoDB database port | β | undefined |
If set, must be a number between 0 and 65535 |
DATABASE_NAME |
MongoDB database name | β | β | Can't be empty string |
DATABASE_USERNAME |
MongoDB database user | β | β | Can't be empty string |
DATABASE_PASSWORD |
MongoDB database password | β | β | Can't be empty string |
CORS_ORIGIN |
CORS allowed origin | β | * |
If set, can't be empty string |
In order to keep the code clean, consistent and free of bad TS practices, more than 300 ESLint rules are activated !
Complete list of all enabled rules is available in the .eslintrc.js file.
Before linting, you must follow the installation steps.
Then, run one of the following commands :
# Lint
pnpm run lint
# Lint and fix
pnpm run lint:fix
# Lint and fix only on staged files (runs on pre-commit)
pnpm run lint:staged:fix
# Display all configs and rules used in browser using @eslint/config-inspector
pnpm run lint:inspect-config
Multiple tools are set up to maintain the best code quality and to prevent vulnerabilities :
You can check the CodeQL analysis report here.
SonarCloud summary is available here.
Releases on main branch are generated and published automatically by :
It uses the conventional commit strategy.
Each change when a new release comes up is listed in the CHANGELOG.md file.
Also, you can keep up with changes by watching releases via the Watch GitHub button at the top of this page.
This project uses GitHub Actions to automate some boring tasks.
You can find all the workflows in the .github/workflows directory.
Name | Description & Status | Triggered on |
---|---|---|
βοΈ Build | Various checks for app health, code quality and tests coverage |
push on develop and all pull requests to develop |
π Lint PR Name Into Develop Workflow | Checks if pull request name respects conventionnal-commit rules |
pull-request created or updated |
β΅οΈ Push On Develop Branch Workflow | Uploads app with develop version to Docker Hub |
push on develop |
ποΈ Upsert PR Release Workflow | Creates or updates pull request to main depending on commits on develop since last release |
push on develop |
π·οΈ Release Creation Workflow | Creates a new release using semantic-release with tag and updated changelog |
push on main |
π Deploy To Production Workflow | Deploys app with last tag version to Docker Hub and GCP |
tag-creation |
π³ Animated tree visualisation of the project's evolution with Gource
# Please ensure that `gource` is installed on your system.
pnpm run gource
pnpm run script:create-branch
pnpm run script:create-pull-request
All the above commands are available in the .run directory at the root of the project.
You can add them as run configurations in your IDE.
This project is licensed under the MIT License.
There is no contributor yet. Want to be the first ?
If you want to contribute to this project, please read the contribution guide.