Skip to content

Commit 5f68356

Browse files
kwonojbenlesh
authored andcommitted
chore(package.json): add commit message format helper script
1 parent 0329b50 commit 5f68356

File tree

2 files changed

+21
-12
lines changed

2 files changed

+21
-12
lines changed

CONTRIBUTING.md

Lines changed: 12 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -101,9 +101,9 @@ from the main (upstream) repository:
101101
102102
### <a id="unit-tests"></a>Unit Tests
103103
104-
Unit tests are located under the [spec directory](/spec). Unit tests over synchronous operators and operations
105-
can be written in a standard [jasmine](http://jasmine.github.io/) style. Unit tests written against any
106-
asynchronous operator should be written in [Marble Test Style outlined in detail here](docs/writing-marble-tests.md).
104+
Unit tests are located under the [spec directory](/spec). Unit tests over synchronous operators and operations
105+
can be written in a standard [jasmine](http://jasmine.github.io/) style. Unit tests written against any
106+
asynchronous operator should be written in [Marble Test Style outlined in detail here](docs/writing-marble-tests.md).
107107
108108
Each operator under test must be in its own file to cover the following cases:
109109
@@ -114,7 +114,7 @@ Each operator under test must be in its own file to cover the following cases:
114114
- Never ending sequences
115115
- Early disposal in sequences
116116
117-
If the operator accepts a function as an argument from the user/developer (for example `filter(fn)` or `zip(a, fn)`),
117+
If the operator accepts a function as an argument from the user/developer (for example `filter(fn)` or `zip(a, fn)`),
118118
then it must cover the following cases:
119119
120120
- Success with all values in the callback
@@ -135,19 +135,19 @@ testing techniques.
135135
- DO add performance tests that you feel are missing from other operators
136136
- DO add additional performance tests for all worthy code paths. If you develop an operator with special handling for scalar observables,
137137
please add tests for those scenarios
138-
138+
139139

140140
#### <a id="macro"></a>Macro
141-
141+
142142
[Macro performance tests](perf/macro) are best written for scenarios where many object instance allocations (or deallocations) are occuring. Operators
143-
that create a lot of child subscriptions, or operators that emit new objects like Observables and Subjects are definitely worth creating
143+
that create a lot of child subscriptions, or operators that emit new objects like Observables and Subjects are definitely worth creating
144144
macro performance tests for.
145145

146-
Other scenarios for macro performance testing may include common end-to-end scenarios from real-world apps. If you have a situation in your
146+
Other scenarios for macro performance testing may include common end-to-end scenarios from real-world apps. If you have a situation in your
147147
app where you feal RxJS is performing poorly, please [submit and issue](/ReactiveX/RxJS/issues) and include a minimal code example showing
148148
your performance issues. We would love to solve perf for your real-world problems and add those tests to our perf test battery.
149149

150-
Macro performance tests can be run by hosting the root directory with any web server (we use [http-server](https://www.npmjs.com/package/http-server)),
150+
Macro performance tests can be run by hosting the root directory with any web server (we use [http-server](https://www.npmjs.com/package/http-server)),
151151
then running:
152152

153153
```sh
@@ -177,8 +177,9 @@ node perf/micro zip
177177
## <a name="commit"></a> Commit Message Guidelines
178178
179179
We have very precise rules over how our git commit messages can be formatted. This leads to **more
180-
readable messages** that are easy to follow when looking through the **project history**. But also,
181-
we use the git commit messages to **generate the RxJS change log**.
180+
readable messages** that are easy to follow when looking through the **project history**. But also,
181+
we use the git commit messages to **generate the RxJS change log**. Helper script `npm run commit`
182+
provides commandline based wizard to format commit message easily.
182183
183184
### Commit Message Format
184185
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special

package.json

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,6 +3,11 @@
33
"version": "5.0.0-alpha.6",
44
"description": "Reactive Extensions for modern JavaScript",
55
"main": "index.js",
6+
"config": {
7+
"commitizen": {
8+
"path": "node_modules/cz-conventional-changelog"
9+
}
10+
},
611
"scripts": {
712
"build_all": "npm run build_es6 && npm run build_amd && npm run build_cjs && npm run build_global",
813
"build_amd": "rm -rf dist/amd && tsc typings/es6-shim/es6-shim.d.ts src/Rx.ts -m amd --outDir dist/amd --sourcemap --target ES5",
@@ -24,7 +29,8 @@
2429
"watch": "watch \"echo triggering build && npm run build_test && echo build completed\" src -d -u -w=15",
2530
"perf": "protractor protractor.conf.js",
2631
"perf_micro": "node ./perf/micro/index.js",
27-
"prepublish": "npm run build_all"
32+
"prepublish": "npm run build_all",
33+
"commit": "git-cz"
2834
},
2935
"repository": {
3036
"type": "git",
@@ -73,7 +79,9 @@
7379
"benchpress": "2.0.0-alpha.37.2",
7480
"browserify": "11.0.0",
7581
"colors": "1.1.2",
82+
"commitizen": "2.3.0",
7683
"coveralls": "2.11.4",
84+
"cz-conventional-changelog": "1.1.4",
7785
"esdoc": "0.2.5",
7886
"eslint": "1.5.1",
7987
"fs-extra": "0.24.0",

0 commit comments

Comments
 (0)