Contribute to codebase

Thank you for considering contributing to erxes! This document will outline how to submit changes to this repository and which conventions to follow. If you are ever in doubt about anything, we encourage you to reach out by submitting an issue here or via Discord.

Prerequisites

• You have to be familiar with GitHub Issues and Pull Requests
• You should to read the docs.
• You make sure you set up a test project with erxes

Issues before PRs

1. Before you start working on a change, please make sure there is an issue with what you will be working on. You can either find an existing issue or open a new issue if none exists. Doing this ensures that others can contribute with thoughts or suggest alternatives, ultimately ensuring that we only add changes that make the most sense for erxes future.
2. When you are ready to start working on a change, you should first fork the erxes repo and branch out from the develop branch.
3. Make your changes.
4. Open a pull request towards the development branch in the erxes repo. Within a couple of days, erxes team members will review, comment, and eventually approve your PR.

Workflow

Branches

All changes should be part of a branch and submitted as a pull request - your branches should be prefixed with one of:

• fix/ for bug fixes
• feat/ for features
• docs/ for documentation changes

Commits

Strive towards keeping your commits small and isolated - this helps the reviewer understand what is going on and makes it easier to process your requests.

Pull Requests

Once your changes are ready, you must submit your branch as a pull request. Your pull request should be opened against the development branch in the main erxes repo.

In your PR's description, you should follow the structure:

• What - what changes are in this PR
• Why - why are these changes relevant
• How - how have the changes been implemented
• Testing - how have the changes been tested or how can the reviewer test the feature

We highly encourage that you do a self-review prior to requesting a review. To do a self-review click the review button in the top right corner, go through your code and annotate your changes. This makes it easier for the reviewer to process your PR.

Merge Style

All pull requests are squashed and merged.

Testing

All PRs should include tests for the changes that are included. We have two types of tests that must be written:

• Unit tests found under packages//src/services/tests and packages//src/api/routes/*/tests
• Integration tests found in integration-tests/*/tests

Documentation

• We generally encourage to document your changes through comments in your code.
• If you alter user-facing behavior, you must provide documentation for such changes.
• All methods and endpoints should be documented using JSDoc and swagger-inline.

Release

The erxes team will regularly create releases from the develop branch.