Coding conventions & Repository guidelines

Github Repository Guidelines

The main branch of this repository is main (see why we don't use master), and it contains the latest functional code. It is continuously deployed to guacamole.valentin-perignon.fr.

Developement (both bug fixes and new features) Pull Request are made against main. They must match several criteria before being merged:

• Pass the Github CI worflows, with node v14, which run tests, ensure that the app still builds, and also checks for linting issues
• Check that images are compressed with the CalibreApp Image Action
• Be reviewed by at least one developer
• The PR must have a proper (read descriptive) title, because it will be the title of the merged commit

Pull Request helper

Create a new branch

git checkout main # go to the main branch
git pull origin main # make sure the branch is up to date
git checkout -b new_branch_name # create the new branch
# ... Write & commit some code
git push origin new_branch_name # push the branch to the github repository

Create the branch Pull Request

• Go on the GitHub repository
• Create the new Pull Request with base : main & compare : new_branch_name ( If you recently push from the branch, GitHub will offer you to create the PR automatically)

Releases

We try to follow the semantic versioning version scheme. Releases and changelog can be found in our Github Releases.

Coding conventions

JavaScript

We use the almost default Prettier configuration, with a printWith of 100 because we have big screens.

SASS

We follow the Sass Pattern 7-1.

Server tests

On the server side, we are used to adding tests for each new feature or code changes. This allows you to maintain control over the completed features.

The tests are separated into several files, but more precisely into several describe blocks. It is important to keep all these blocks independent, in particular, the order of execution should not influence the correct functioning of the tests. Thus, in these blocks, one or more before could be used to put the database in the expected state for the following tests.

Why does this test fail ?

If after a modification an existing test fails, there can be several reasons :

• The test is bad : Possible, but not really likely, you should never delete a test, so think more about it.
• The timeout exceeded : the tests have a maximum timeout to avoid too long waits, if the test is long, you can increase the timeout (Be careful, an exceeded timeout may mask an error).
• Your new code introduces a bug : most likely, check for errors and modify your code until all tests pass.