|
1 | | -Contributing to Pattern Lab Node |
2 | | -================================ |
| 1 | +# Contributing to Pattern Lab Node |
3 | 2 |
|
4 | 3 | If you'd like to contribute to Pattern Lab Node, please do so! There is always a lot of ground to cover and something for your wheelhouse. |
5 | 4 |
|
6 | 5 | No pull request is too small. Check out any [up for grabs issues](https://github.com/pattern-lab/patternlab-node/labels/up%20for%20grabs) as a good way to get your feet wet, or add some more unit tests. |
7 | 6 |
|
8 | | -Developing Locally |
9 | | ------------------- |
| 7 | +## Developing Locally |
10 | 8 |
|
11 | 9 | The best way to make changes to the Pattern Lab Node core and test them is through your existing edition. |
12 | 10 |
|
13 | | -- Fork this repository on Github. |
14 | | -- Create a new branch in your fork and push your changes in that fork. |
15 | | -- `npm install` |
16 | | -- `npm link` |
17 | | -- `cd /path/to/your/edition` |
18 | | -- `npm link patternlab-node` |
| 11 | +* Fork this repository on Github. |
| 12 | +* Create a new branch in your fork and push your changes in that fork. |
| 13 | +* `npm install` |
| 14 | +* `npm link` |
| 15 | +* `cd /path/to/your/edition` |
| 16 | +* `npm link patternlab-node` |
19 | 17 |
|
20 | | -Guidelines |
21 | | ----------- |
| 18 | +## Guidelines |
22 | 19 |
|
23 | | -- *ALWAYS* submit pull requests against the [dev branch](https://github.com/pattern-lab/patternlab-node/tree/dev). If this does not occur, I will first, try to redirect you gently, second, attempt to redirect the target branch myself, thirdly, port over your contribution manually if time allows, and/or lastly, close your pull request. If you have a major feature to stabilize over time, talk to @bmuenzenmeyer via an issue about making a dedicated `feature-branch` |
24 | | -- Keep your pull requests concise and limited to **ONE** substantive change at a time. This makes reviewing and testing so much easier. |
25 | | -- Commits should reference the issue you are adressing. For any Pull Request that you send, use the template provided. |
26 | | -- Commits are best formatted using the [conventional commits pattern](https://conventionalcommits.org/). |
27 | | -- If you can, add some unit tests using the existing patterns in the `./test` directory |
28 | | -- Large enhancements should begin with opening an issue. This will result in a more systematic way for us to review your contribution and determine if a [specifcation discussion](https://github.com/pattern-lab/the-spec/issues) needs to occur. |
29 | | -- Mention the issue number in commits, so anyone can see to which issue your changes belong to. For instance: |
30 | | - - `#123 Fix resolving patterns in pattern_hunter` |
31 | | - - `Feature #42: improve improbability drive` |
| 20 | +* _ALWAYS_ submit pull requests against the [dev branch](https://github.com/pattern-lab/patternlab-node/tree/dev). If this does not occur, I will first, try to redirect you gently, second, attempt to redirect the target branch myself, thirdly, port over your contribution manually if time allows, and/or lastly, close your pull request. If you have a major feature to stabilize over time, talk to @bmuenzenmeyer via an issue about making a dedicated `feature-branch` |
| 21 | +* Keep your pull requests concise and limited to **ONE** substantive change at a time. This makes reviewing and testing so much easier. |
| 22 | +* Commits should reference the issue you are adressing. For any Pull Request that you send, use the template provided. |
| 23 | +* Commits are best formatted using the [conventional commits pattern](https://conventionalcommits.org/). |
| 24 | +* If you can, add some unit tests using the existing patterns in the `./test` directory |
| 25 | +* Large enhancements should begin with opening an issue. This will result in a more systematic way for us to review your contribution and determine if a [specifcation discussion](https://github.com/pattern-lab/the-spec/issues) needs to occur. |
| 26 | +* Mention the issue number in commits, so anyone can see to which issue your changes belong to. For instance: |
| 27 | + * `#123 Fix resolving patterns in pattern_hunter` |
| 28 | + * `Feature #42: improve improbability drive` |
32 | 29 |
|
33 | | -Coding style |
34 | | ------------- |
| 30 | +## Coding style |
35 | 31 |
|
36 | | -Two files combine within the project to define and maintain our coding style. |
| 32 | +Formatting is automated via [Prettier](https://prettier.io/), setup to run on precommit. We suggest [editor integration](https://prettier.io/docs/en/editors.html) for this and for eslint. Prettier is further configured within `.prettierrc`. Eslint validates syntax and usage that Prettier doesn't handle. Configuration for both is found within the `.eslintrc` file. |
37 | 33 |
|
38 | | -- The `.editorconfig` controls spaces / tabs within supported editors. Check out their [site](http://editorconfig.org/). |
39 | | -- The `.eslintrc` defines our javascript standards. Some editors will evaluate this real-time - otherwise it's run using `grunt|gulp build` |
| 34 | +The `.editorconfig` controls spaces / tabs within supported editors. Check out their [site](http://editorconfig.org/). |
40 | 35 |
|
41 | | -Tests |
42 | | ------ |
| 36 | +## Tests |
43 | 37 |
|
44 | 38 | Add unit and integration tests if you can. It's always nice if our code coverage improves bit by bit (literally!). We are using [Node Tap](http://www.node-tap.org/) as test framework and [Rewire](https://github.com/jhnns/rewire) for mocking things like file system access. |
45 | 39 |
|
46 | | -Branching Scheme |
47 | | ----------------- |
| 40 | +## Branching Scheme |
48 | 41 |
|
49 | 42 |  Currently Pattern Lab has the following branches: |
50 | 43 |
|
51 | | -- **master** contains the latext stable, released version</dd> |
52 | | -- **dev**: for development. *Target pull requests against this branch.* |
53 | | -- **feature-branches** for larger changes. Allows merging all changes into both `dev` easily. |
54 | | -- **long running branches** for changes that involve major changes to the code, architecture and take a lot of time (i.e. making Pattern Lab async) |
| 44 | +* **master** contains the latext stable, released version</dd> |
| 45 | +* **dev**: for development. _Target pull requests against this branch._ |
| 46 | +* **feature-branches** for larger changes. Allows merging all changes into both `dev` easily. |
| 47 | +* **long running branches** for changes that involve major changes to the code, architecture and take a lot of time (i.e. making Pattern Lab async) |
55 | 48 |
|
56 | 49 | New features are typically cut off of `dev` branch. When `dev` is stable cut releases by merging `dev` to `master` and creating a release tag. |
57 | 50 |
|
58 | | -Gitter.im Chat |
59 | | -============== |
| 51 | +# Gitter.im Chat |
60 | 52 |
|
61 | 53 | If you have any questions or you would like to help, feel free to ask on [our Gitter.im channel](https://gitter.im/pattern-lab/node) :smiley: |
0 commit comments