UNPKG

5.42 kBMarkdownView Raw
1# Contributing to Sinon.JS
2
3There are several ways of contributing to Sinon.JS
4
5* Look into [issues tagged `help-wanted`](https://github.com/sinonjs/sinon/issues?q=is%3Aopen+is%3Aissue+label%3A%22Help+wanted%22)
6* Help [improve the documentation](https://github.com/sinonjs/sinon/tree/master/docs) published
7 at [the Sinon.JS website](https://sinonjs.org). [Documentation issues](https://github.com/sinonjs/sinon/issues?q=is%3Aopen+is%3Aissue+label%3ADocumentation).
8* Help someone understand and use Sinon.JS on [Stack Overflow](https://stackoverflow.com/questions/tagged/sinon)
9* Report an issue, please read instructions below
10* Help with triaging the [issues](https://github.com/sinonjs/sinon/issues). The clearer they are, the more likely they are to be fixed soon.
11* Contribute to the code base.
12
13## Reporting an issue
14
15To save everyone time and make it much more likely for your issue to be understood, worked on and resolved quickly, it would help if you're mindful of [How to Report Bugs Effectively](http://www.chiark.greenend.org.uk/~sgtatham/bugs.html) when pressing the "Submit new issue" button.
16
17As a minimum, please report the following:
18
19* Which environment are you using? Browser? Node? Which version(s)?
20* Which version of SinonJS?
21* How are you loading SinonJS?
22* What other libraries are you using?
23* What you expected to happen
24* What actually happens
25* Describe **with code** how to reproduce the faulty behaviour
26
27See [our issue template](https://github.com/sinonjs/sinon/blob/master/.github/) for all details.
28
29## Contributing to the code base
30
31Pick [an issue](https://github.com/sinonjs/sinon/issues) to fix, or pitch
32new features. To avoid wasting your time, please ask for feedback on feature
33suggestions with [an issue](https://github.com/sinonjs/sinon/issues/new).
34
35Make sure you have read [GitHub's guide on forking](https://guides.github.com/activities/forking/). It explains the general contribution process and key concepts.
36
37### Making a pull request
38
39Please try to [write great commit messages](http://chris.beams.io/posts/git-commit/).
40
41There are numerous benefits to great commit messages
42
43* They allow Sinon.JS users to understand the consequences of updating to a newer version
44* They help contributors understand what is going on with the codebase, allowing features and fixes to be developed faster
45* They save maintainers time when compiling the changelog for a new release
46
47If you're already a few commits in by the time you read this, you can still [change your commit messages](https://help.github.com/articles/changing-a-commit-message/).
48
49Also, before making your pull request, consider if your commits make sense on their own (and potentially should be multiple pull requests) or if they can be squashed down to one commit (with a great message). There are no hard and fast rules about this, but being mindful of your readers greatly help you author good commits.
50
51### Use EditorConfig
52
53To save everyone some time, please use [EditorConfig](http://editorconfig.org), so your editor helps make
54sure we all use the same encoding, indentation, line endings, etc.
55
56### Installation
57
58The Sinon.JS developer environment requires Node/NPM. Please make sure you have
59Node installed, and install Sinon's dependencies:
60
61 $ npm install
62
63This will also install a pre-commit hook, that runs style validation on staged files.
64
65
66### Compatibility
67
68For details on compatibility and browser support, please see [`COMPATIBILITY.md`](COMPATIBILITY.md)
69
70### Linting and style
71
72Sinon.JS uses [ESLint](http://eslint.org) to keep the codebase free of lint, and uses [Prettier](https://prettier.io) to keep consistent style.
73
74If you are contributing to a Sinon project, you'll probably want to configure your editors ([ESLint](https://eslint.org/docs/user-guide/integrations#editors), [Prettier](https://prettier.io/docs/en/editors.html)) to make editing code a more enjoyable experience.
75
76The ESLint verification (which includes Prettier) will be run before unit tests in the CI environment. The build will fail if the source code does not pass the style check.
77
78
79You can run the linter locally:
80
81```
82$ npm run lint
83```
84
85You can fix a lot lint and style violations automatically:
86
87```
88$ npm run lint -- --fix
89```
90
91To ensure consistent reporting of lint warnings, you should use the same versions of ESLint and Prettier as defined in `package.json` (which is what the CI servers use).
92
93### Run the tests
94
95Following command runs unit tests in PhantomJS, Node and WebWorker
96
97 $ npm test
98
99##### Testing in development
100
101Sinon.JS uses [Mocha](https://mochajs.org/), please read those docs if you're unfamiliar with it.
102
103If you're doing more than a one line edit, you'll want to have finer control and less restarting of the Mocha
104
105To start tests in dev mode run
106
107 $ npm run test-dev
108
109Dev mode features:
110 * [watching related files](https://mochajs.org/#w---watch) to restart tests once changes are made
111 * using [Min reporter](https://mochajs.org/#min), which cleans the console each time tests run, so test results are always on top
112
113Note that in dev mode tests run only in Node. Before creating your PR please ensure tests are passing in Phantom and WebWorker as well. To check this please use [Run the tests](#run-the-tests) instructions.
114
115### Compiling a built version
116
117Build requires Node. Under the hood [Browserify](http://browserify.org/) is used.
118
119To build run
120
121 $ node build.js
122
123