Contributing

Table of contents

Local development

Nix is used extensively for the local development setup. So you should get it by going to the Nix installation page.

Virtual machine

The website directory used by the virtual machine needs to be created and the NodeJS process, which typically runs as the default system user, needs permission to write to this directory.

This can be achieved using the following commands:

sudo mkdir -p /var/www/archtika-websites

sudo chown $USER:$(id -gn) /var/www/archtika-websites

nix run .#dev-vm

REST API

Now that the virtual machine containing the PostgreSQL server is running, the PostgREST API can be launched.

The following command can be run to automatically perform all database migrations and then start the API:

nix run .#api

Web application

Finally, the web application must be accessible.

This can be achieved by running the following commands:

cd web-app

nix develop .#web

npm install

npm run dev

Once this is done, the application can be accessed via localhost:5173 and all communication and functionality should now work.

Conventions

  • For the web application, make sure you format and lint your code using the provided npm run lint and npm run format scripts. End-to-end tests are run automatically on repository push, but can also be run locally using the npm run test command. If you change the database structure by adding a new migration, make sure you use the npm run gents command to generate the new TypeScript types
  • After adding a new database migration, format your SQL code using the formatsql command (alias accessible after running nix develop .#api)
  • If any changes are made to files in the nix directory, use the nix fmt command to format the code

Adding changes to the GitHub repository

There are two main branches, the devel branch and the main branch. Before anything goes to main, it first goes to devel.

So if a person wants to add a change to the main system, the following process must be completed:

  1. Fork the repository
  2. Create a feature branch
  3. Make the desired changes
  4. Create a pull request for the devel branch
  5. Wait for merge from reviewer
  6. If necessary, manually test the changes on the QA instance
  7. Reviewer opens pull request for main branch, and if all tests pass, merges it