|
| 1 | +# Contributing |
| 2 | +So you want to contribute to ATLauncher? Well here are a few ways you can help make this project better! |
| 3 | + |
| 4 | +## Branching structure |
| 5 | +When contributing please follow our branching structure when making a PR. Not following this will result in automatic |
| 6 | +closure of the PR. |
| 7 | + |
| 8 | +Our branching structure is based on |
| 9 | +[Gitflow Workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow). |
| 10 | + |
| 11 | + - **master** will always contain the code for the latest production release |
| 12 | + - **develop** will contain the latest beta version used for testing |
| 13 | + - **feature/*** will contain single issues being developed. Once developed they're merged into develop and tagged with |
| 14 | + a beta release version. They should be named 'feature/22-some-brief-description' |
| 15 | + - **release/*** will contain all the code from each feature branch that are going out in the next release and should |
| 16 | + all be merged into the branch. Once approved and tested it gets merged into master and tagged. They |
| 17 | + should be named 'release/4-1-1-release' |
| 18 | + - **hotfix/*** will contain hotfixes going to be merged directly into master then tagged. Hotfixes should only need to |
| 19 | + occur when there is a very critical bug in the current release that needs to be fixed ASAP. All hotfix |
| 20 | + branches should be branched off of master. |
| 21 | + |
| 22 | +All tags are done on release of a beta or a production version and should be in format **v(version number)** and the |
| 23 | +version number being that of a semver number. |
| 24 | + |
| 25 | +All develop releases should be tagged with **beta** versions. For instance **v4.1.1-beta.1.6** where the NPM package |
| 26 | +version would be **4.1.1-beta.1.6**. Alpha versions shouldn't be used. |
| 27 | + |
| 28 | +Feature branches are deleted once in a release branch. Any issues that come up after the features branch has been merged |
| 29 | +nto a release branch should be resolved by creating a new feature branch off the release branch. |
| 30 | + |
| 31 | +An example of a good name for a feature branch is say we have an issue (#44) which is about not being able to delete a |
| 32 | +pack. A good name for a feature branch would be `feature/44-unable-to-delete-packs` and go from there. |
| 33 | + |
| 34 | +## Code styling |
| 35 | +When creating a PR all code you've committed will be linted against our defined ESLint rules. You can check if your code |
| 36 | +follows our standards by running the `npm run lint` command. More information about our ESLint rules can be found |
| 37 | +[here](https://github.com/ATLauncher/style-guide/tree/master/packages/eslint-config-atlauncher). |
| 38 | + |
| 39 | +In short please note the following: |
| 40 | + |
| 41 | + - All line lengths should be under 120 lines long. |
| 42 | + - 4 spaces in all files (other than json files which use 2 spaces). |
| 43 | + - Unix newlines should **ALWAYS** be used. |
| 44 | + - Single quotes should be used everywhere when possible except for JSON. |
| 45 | + - All code should contain correct JSDoc documentation. |
| 46 | + |
| 47 | +## Testing |
| 48 | +All new code created should be properly tested with both unit and end to end tests where appropriate. |
| 49 | + |
| 50 | +Please don't over test your code, we don't aim for complete code coverage and don't even use that as a metric, we simply |
| 51 | +want to make sure all code is tested for typical happy and sad paths, making sure as many use cases are accounted for. |
| 52 | + |
| 53 | +## Discord |
| 54 | +If you wish to join our Discord channel please do so [here](https://atl.pw/discord). There is a channel specifically for |
| 55 | +NEXT discussion called **#atlauncher-next** which you can feel free to contribute to. |
0 commit comments