Skip to content

Latest commit

 

History

History
106 lines (67 loc) · 6.34 KB

CONTRIBUTING.md

File metadata and controls

106 lines (67 loc) · 6.34 KB

Welcome to the OpenVisit contribution guideline

Thank you for investing your time to contribute to OpenVisit!

In this guide you will get an overview of the contribution workflow from opening an issue, creating a PR, reviewing and merging the PR.

New contributor guide

To get an overview of the project, read the root README. Bellow, are some resources that will help you with open source contributions:

Contribution workflow

Dependencies

This project uses pnpm, and should be run with Node.js on the latest available LTS version. Ensure you have the following dependencies setup:

Refer to their respective documentation for installation instructions.

Important

The mentioned dependencies are necessary for local development, specifically pnpm. Running project commands with either npm or yarn will wield unexpected errors.

Running locally

To clone the project locally:

  • git clone https://github.com/thtsystems/open-visit.git for HTTP or git clone [email protected]:thtsystems/open-visit.git for SSH
  • cd open-visit

This is the project's directory structure:

📦 <project root>
 ├ 📂 api ## Source code for API service running on Cloudflare Workers, written with Hono & Lucia.
 ├ 📂 database ## Configuration for the database connection and schema modeling using Drizzle.
 ├ 📂 web ## Web client application in React.

Some modules are shared with each other trough the Workspace feature from the pnpm package manager. For example, the @open-visit/api module imports the @open-visit/database module to connect to the database.

To install the dependencies, run pnpm install on the root directory. This will install the dependencies for all workspaces, including the ones under child directories.

Running the database container with Docker

First, make sure Docker is installed, and that the daemon service is running. You can check if the daemon is running by running docker info on the command line.

Run docker compose up -d to start the database container in the background (you can ommit the -d flag if you want to see the running logs for the Docker containers).

Once the container setup is finished those resources will be available:

  • The database instance, running locally on postgres://localhost:5432
  • A web based instance og pgAdmin that can be used to visualize and interact visually with the database, running locally on http://localhost:5050

You can customize how you access both resources by creating new values on an .env file on the root directory. Unless explicitly specified, the default values will be used.

These are the default values:

POSTGRES_USER=postgres
POSTGRES_PASSWORD=postgres
PGADMIN_PORT=5050
[email protected]
PGADMIN_DEFAULT_PASSWORD=admin

Which means that, to access the database, you'll use the connection string postgres://postgres:postgres@localhost:5432, and to access the pgAdmin panel, you'll go to http://localhost:5050 in the browser and use [email protected] as the email and admin as the password during authentication.

Setting up the database

Before running the application, you should setup the database schema.

  1. Run docker compose up -d from the root of the project to initialize the database container.
  2. On another terminal instance, in the root directory of the project, run pnpm db:push to push the schema definitions to the database.

Running the services

With the database properly setup, all you need to do now is run the services. From the root of the project, you can run pnpm dev, and all the services will run concurrently using Turbo. Alternatively, you can run each service individually in seperate terminal instances by running cd <workspace_directory> and pnpm dev on each one.

Pull Request

When you're finished with the changes, create a pull request.

  • Fill the "Ready for review" template so that we can review your PR. This template helps reviewers understand your changes as well as the purpose of your pull request.
  • Don't forget to link PR to issue if you are solving one.
  • Enable the checkbox to allow maintainer edits so the branch can be updated for a merge. Once you submit your PR, a team member will review your proposal. We may ask questions or request for additional information.
  • We may ask for changes to be made before a PR can be merged, either using suggested changes or pull request comments. You can apply suggested changes directly through the UI. You can make any other changes in your fork, then commit them to your branch.
  • As you update your PR and apply changes, mark each conversation as resolved.
  • If you run into any merge issues, checkout this git tutorial to help you resolve merge conflicts and other issues.

It is possible that your pull request is denied if it does not align with our current development goals, but we'll try our best to make sure you receive feedback with detailed information as to why it has been rejected.

Your PR is merged!

Congratulations 🎉🎉 The community of OpenVisit maintainers and users thanks you for your contribution ✨

Credits

This CONTRIBUTING.md file was modelled after the github/docs CONTRIBUTING.md file, and we thank the original author.