|
1 | 1 | # Contributing 👥 |
2 | 2 |
|
3 | | -Streamability is very open to contributions! If you have a feature request or bug report, please open an [issue](https://github.com/Thenlie/Streamability/issues) with the applicable tag. If you would like to create a feature yourself, [fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks) the repository and add in your changes. Then submit a [pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) which will be reviewed and eventually merged if it meets all contribution requirements. You can find out more about these requirements in the [contribution guidelines](https://github.com/Thenlie/Streamability/blob/main/docs/contribution-guidelines.md). |
| 3 | +Streamability is very open to contributions! If you have a feature request or bug report, please open an [issue](https://github.com/Thenlie/Streamability/issues) with the applicable tag. If you would like to create a feature yourself, [fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks) the repository and add in your changes. Then submit a [pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) which will be reviewed and eventually merged if it meets all contribution requirements. |
4 | 4 |
|
5 | 5 | --- |
6 | 6 |
|
7 | | -# Branching Strategy 🌲 |
| 7 | +## Branching Strategy 🌲 |
8 | 8 |
|
9 | 9 | When creating branches, be sure to use the proper naming convention. Each item should by hyphen separated and lowercase. |
10 | 10 |
|
11 | | -1. Issue number. If no issue, `NA-0` |
12 | | -2. Issue type. If no issue, pick the most suitable type. |
13 | | -3. Description. |
| 11 | +1. Issue number. If no issue, `0` |
| 12 | +2. Description. |
14 | 13 |
|
15 | 14 | Example: |
16 | | -``` |
17 | | -13-feat-show-card |
18 | | -``` |
19 | | - |
20 | | -You should branch off of the `develop` branch, not `main` as this is where all PRs will point. Be sure your branch is up to date before submitting PRs by running `git rebase develop` while checked out to your branch. You can read more about this below. |
21 | | - |
22 | | ---- |
23 | | - |
24 | | -# Git Workflow 🧬 |
25 | | - |
26 | | -Streamability V2 is attempting to have a linear commit history on `main` as well as `develop`. You can read more about the benefits of linear commit histories [here](https://www.bitsnbites.eu/a-tidy-linear-git-history/#:~:text=A%20linear%20history%20is%20simply,branches%20with%20independent%20commit%20histories.). |
27 | | - |
28 | | -Creating and pushing a new feature branch is quite simple. Follow the steps below: |
29 | | - |
30 | | -1. Checkout to `develop` and pull the most recent changes. |
31 | | -```s |
32 | | -git pull origin develop |
33 | | -``` |
34 | | - |
35 | | -2. Create a new feature branch using the proper naming convention. |
36 | | -```s |
37 | | -git checkout -b <"issue-num"-"issue-type"-"branch-name"> |
38 | | -``` |
39 | | -> NOTE: If you do not have an issue number or type, `NA-0`, should be used instead followed by the branch name. |
40 | | -> |
41 | | -> The branch name is whatever the developer thinks fits best but should be descriptive, lowercase, and hyphen separated. |
42 | | -
|
43 | | -3. Add your changes to the branch and create a new commit. The commit should contain a descriptive message of the changes or additions you have made. It is also a good idea to run an es-lint check first. |
44 | | -```s |
45 | | -npm run lint |
46 | | -git add -A |
47 | | -git commit -m "descriptive message" |
48 | | -``` |
49 | | -> One common issue when learning to work with linear histories is avoiding merge commits. As an example, if you are on `feature` and another developer merges a pull request to `develop`, using the command `git merge develop` will create a merge commit on the feature branch log. Assuming the code added to develop is unrelated to the feature,this is an unnecessary commit on the feature branch. To avoid this, `git rebase develop` should be used instead. |
50 | | -
|
51 | | -4. Push your branch to the remote repository |
52 | | -```s |
53 | | -git push origin branch-name |
54 | | -``` |
55 | | -> NOTE: This assumes you named the remote `origin`. |
56 | 15 |
|
57 | | -5. If you need to make changes to your code after the PR review, you can do so and add, then commit as normal. After you have done this use an interactive rebase to squash the commits into as few as possible. You will then need to force push your branch back to the remote. |
58 | | -```s |
59 | | -git rebase -i HEAD~2 |
60 | | -... |
61 | | -git push -f origin branch-name |
| 16 | +```txt |
| 17 | +123-update-readme |
62 | 18 | ``` |
63 | | -> NOTE: `HEAD~2` would pick the current HEAD and on commit previous for the rebase. Change this number as needed depending on the number of commits you have. You can read more about rebasing [here](https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase). |
64 | | -
|
65 | | -## Work-in-Progress Commits |
66 | 19 |
|
67 | | -If you would like to make commits without running the full test suite, you can do so with the following command: |
68 | | -```s |
69 | | -git commit -m "msg" --no-verify |
70 | | -``` |
71 | | -You can also set an environment flag in you shell to do this. Here is a helpful script for quickly creating WIP commits: |
72 | | -```s |
73 | | -export NO_VERIFY=1 && git add -A && git commit -m "CI Skipped. --WIP--" && export NO_VERIFY= |
74 | | -``` |
| 20 | +You should branch off of the `develop` branch, not `main` as this is where all PRs will point. Be sure your branch is up to date before submitting PRs by running `git rebase develop` while checked out to your branch. |
75 | 21 |
|
76 | 22 | --- |
77 | 23 |
|
78 | | -# Code Quality 🧼 |
| 24 | +## Code Quality 🧼 |
79 | 25 |
|
80 | | -## ES Lint |
| 26 | +### ES Lint & Prettier |
81 | 27 |
|
82 | | -In order to make it easier for lots of people to contribute to the project, we want to maintain a high standard of code. To help achieve this, [ES Lint](https://eslint.org/) has been set up in the project. It has also been added to an automation that will run on each PR. Your PR will be blocked if the lint check fails, so be sure not run lint check locally before pushing. To do this, use the commands below. |
| 28 | +To make it easier for many people to contribute to the project, we want to maintain a high standard of code. To help achieve this, [ES Lint](https://eslint.org/) has been set up in the project. It has also been added to an automation that will run on each commit and PR. To run the lint checks manually, use the commands below. [Prettier](https://prettier.io/) is also being used as an ES Lint rule. |
83 | 29 |
|
84 | 30 | Run lint check, returns errors and warnings: |
85 | | -```s |
| 31 | + |
| 32 | +```sh |
86 | 33 | npm run lint |
87 | 34 | ``` |
| 35 | + |
88 | 36 | Run lint check and fix any errors it can: |
89 | | -```s |
| 37 | + |
| 38 | +```sh |
90 | 39 | npm run lint-fix |
91 | 40 | ``` |
92 | 41 |
|
93 | | -ES Lint will throw warnings for implicit use of the `any` type. This should be avoided whenever possible, but can also be ignored with an es-lint flag when absolutely necessary. |
| 42 | +ES Lint will throw errors for the use of the `any` type. This should be avoided whenever possible, but can also be ignored with an es-lint-ignore comment when absolutely necessary. |
94 | 43 |
|
95 | 44 | Should you encounter an area where es-lint and prettier conflict, ignore prettier first. |
96 | 45 |
|
97 | | -## TypeScript |
| 46 | +If you notice that your editor makes changes that the commands above do not, only use the changes made by the commands. You may need to disable format-on-save if you local config conflicts with repositories. |
| 47 | + |
| 48 | +### TypeScript |
98 | 49 |
|
99 | 50 | The easiest way to check for typescript issues is to run the command `npm run watch`. This will run the TypeScript compiler in watch mode so errors and warning will automatically update on save. If you would like to just run the compiler once, use `npm run compile`. |
100 | 51 |
|
101 | 52 | TypeScript also has a standardized comment syntax that should be followed for primary components/functions. |
102 | 53 |
|
103 | | -## Logs |
| 54 | +### Logs |
104 | 55 |
|
105 | 56 | Console logs may not be left in the code. If you need to log an error, or a debug log for some reason, you can use the [Logger](https://github.com/Thenlie/Streamability/blob/main/src/logger.ts) class. This will strip the logs from production builds. See the snippet below for an example of how to use the logger. |
106 | 57 |
|
107 | | -```js |
| 58 | +```ts |
108 | 59 | const LOG = new Logger('ScreenName'); |
109 | 60 |
|
110 | 61 | LOG.error('my custom error message'); |
111 | 62 | LOG.debug('my custom debug message'); |
112 | 63 | ``` |
113 | | - |
114 | | -# Testing 🧪 |
115 | | - |
116 | | -This project features a Vitest testing suite. All tests will need to pass in order for PR's to main or develop to be unblocked. You can run these tests locally with the commands below: |
117 | | -```s |
118 | | -npm test |
119 | | -``` |
120 | | - |
121 | | -To run the tests in watch mode: |
122 | | -```s |
123 | | -npm test -- -w |
124 | | -``` |
125 | | - |
126 | | -To run a single test: |
127 | | -```s |
128 | | -npm test <test-name> |
129 | | -``` |
130 | | - |
131 | | -These tests will be run on each commit. See [work in progress commits](#work-in-progress-commits) if you would like to bypass this behavior. |
0 commit comments