This repository was archived by the owner on Dec 27, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathCONTRIBUTING
74 lines (51 loc) · 4.56 KB
/
CONTRIBUTING
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
# Contributing to SakuraApi/core
First, thanks for giving back to the community! So few people take the time to contribute to open source projects, so it's really great that you're giving back. Thank you.
## Code of Conduct
Please make sure you understand the [Code of Conduct](CODE_OF_CONDUCT.md). By participating, you are agreeing to respect and promote this code when interacting with this community.
## How can I contribute?
### Reporting bugs
Open an issue here: https://github.com/sakuraapi/core/issues
Make sure you clearly explain:
1. All of your versions
2. Expected behavior
3. Actual behavior
4. Steps to reproduce
For example:
```
# Versions
SakuraApi/core: v0.11.0
SakuraApi/auth-native-authority: v0.7.0
node: v8.9.1
# Expected behavior:
When passing an object not decorated with `@Injectable` into `SakuraApi.getProvider` a helpful and specific error should be throw that states the name of the Object that was passed in and that it is not decrated with `@Injectable`.
# Actual behavior:
SakuraApi throws a generic error that's confusing and not helpful: `Unable to get property 'isSakuraApiProvider' of undefined or null`.
# Steps to reproduce:
1. Create a class `Test`, but do not decorate it with @Injectable
2. Instantiate (`sapi`) an instance of SakuraApi, but do not pass the `Test` class into the providers array (this would throw a different error).
3. Call `sapi.getProvider(Test);`
```
If you want to make it even easier for the team to diagnose and resolve your issue, create a public github repo with the minimal working example to reproduce your bug. An easy way to do this is to use `sakuraapi/cli`'s `sapi init sample` to scaffold a minimal project then add the minimum amount of code necessary to reproduce your bug. Share the link to your github.com repo on the issue you open. When you do this, still provide a robust description of the issue as described above.
Extra-credit if you open a pull request with a breaking unit test that proves the bug. (See 'Contributing Code' blow).
Super-bonus-points if you submit a pull request with the breaking unit test and the fix! :)
If you go for the extra-credit or super-bonus-points, make sure you still open an issue.
### Contributing code
[](https://cla-assistant.io/sakuraapi/core)
* Sign the Contributor License Agreement (CLA): https://cla-assistant.io/sakuraapi/core
* Fork the project; make your contribution (don't forget to write your unit-tests); do a pull request back to develop (pull updates frequently to not fall too far behind)
* Before heading off to work on something, considering collaborating first by either (1) opening an issue or (2) starting a conversation on gitter or in the Google forum that leads to back to (1)
* All work should be done against an issue (https://github.com/sakuraapi/api/issues)
* All contributions require unit-tests
* Use the linter (npm run lint) to verify you comply with the style guide
* Reset your changes to the docs/ directory before submitting changes - that directory is generated by TypeDoc and we only update it when we're releasing new updates. If you want to update the documentation, change the appropriate comments in the code.
* Make sure you understand the coding guidelines described below
# Coding Guidelines
## Code
* Follow the patterns found in the file you're modifying
* Lint
* Be ready and open to specific feedback from the team about your contribution. Don't take it as criticism; your contribution is important and deeply appreciated. We're just trying to make sure that the codebase is kept as consistent as possible and that your code makes it into a release so that everyone can benefit from it. :)
## Unit testing
* All code contributed should be accompanied by unit tests that prove the code is working
* Keep tests with their corresponding functionality. For example, if you add a `.foobar()` method to `Model`, the unit tests should be in `model.spec.ts`.
* Keep `SakuraApi.ts` tests close to their decorators if the functionality is related to a decorator. For example, tests exercising the proper function of `@Injectable` decoration by `SakurApi` should be in `injectable.spec.ts`. This is done in order to keep the `sakura-api.spec.ts` file down to a reasonable size. It's also done to keep tests related to each other close together.
* Group related tests together using Jasmine's `describe` feature. For example, if you add `.fooBar()` to `model.ts`, and you have a number of tests related to that, create a `describe` section in `model.spec.ts` titled `.foobar` and place the `it` assertions under that.