From 289ea3c6d5908c7d155e7e65df87895a9e5e1ee7 Mon Sep 17 00:00:00 2001 From: Sarbbottam Bandyopadhyay Date: Fri, 6 May 2016 19:50:04 -0700 Subject: [PATCH] docs(doctoc): using doctoc to generate ToC currently only for CONTRIBUTING.md --- CONTRIBUTING.md | 41 +++++++++++++++++++++++++++++++++-------- package.json | 2 ++ 2 files changed, 35 insertions(+), 8 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0b0ee45e26..e051cc79c5 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -4,6 +4,31 @@ it still applies to you. Ignorance is not an exemption. Contents + + + + + + - [Submitting a Pull Request (PR)](#submitting-a-pull-request-pr) + - [After your pull request is merged](#after-your-pull-request-is-merged) + - [Coding Style Guidelines](#coding-style-guidelines) + - [Unit Tests](#unit-tests) + - [CI Tests](#ci-tests) + - [Performance Tests](#performance-tests) + - [Macro](#macro) + - [Micro](#micro) +- [Commit Message Guidelines](#commit-message-guidelines) + - [Commit Message Format](#commit-message-format) + - [Revert](#revert) + - [Type](#type) + - [Scope](#scope) + - [Subject](#subject) + - [Body](#body) + - [Footer](#footer) + + + +--- - [Pull Requests](#pull-requests) - [Coding Style](#coding) - [Commit Messages](#commit) @@ -16,7 +41,7 @@ Contents (This document is a work and progress and is subject to change) -### Submitting a Pull Request (PR) +### Submitting a Pull Request (PR) Before you submit your Pull Request (PR) consider the following guidelines: * Search [GitHub](https://github.com/ReactiveX/RxJS/pulls) for an open or closed PR @@ -90,7 +115,7 @@ from the main (upstream) repository: git pull --ff upstream master ``` -### Coding Style Guidelines +### Coding Style Guidelines - Please use proper types and generics throughout your code. - 2 space indentation only @@ -99,7 +124,7 @@ from the main (upstream) repository: (TBD): For now try to follow the style that exists elsewhere in the source, and use your best judgment. -### Unit Tests +### Unit Tests Unit tests are located under the [spec directory](/spec). Unit tests over synchronous operators and operations can be written in a standard [jasmine](http://jasmine.github.io/) style. Unit tests written against any @@ -121,14 +146,14 @@ then it must cover the following cases: - Success with the context, if any allowed in the operator signature - If an error is thrown -#### CI Tests +#### CI Tests - Using [Travis](https://travis-ci.org/) on your forked version of RxJS will allow running CI tests on that fork before submitting a PR to master - Simply create a `Travis` account and add your fork as a new project - [Sauce Labs](https://saucelabs.com/) setup will allow performing automated browser tests on the fork. Since `saucelabs` doesn't perform browser tests on a PR, this will help verify test results before PR's are checked into master. - In your `Travis` repo configuration, set the environment variables SAUCE_USERNAME and SAUCE_ACCESS_KEY to your `saucelabs` account ([reference](https://cloud.githubusercontent.com/assets/1210596/12679038/b9ba4eb6-c656-11e5-8c9b-b063c9a3f9dc.png)) - As master runs both of these tests per each check in, it'd be welcome to setup those test before creating your PR -### Performance Tests +### Performance Tests One of the primary goals of this library is (and will continue to be) great performance. As such, we've employed a variety of performance testing techniques. @@ -143,7 +168,7 @@ testing techniques. please add tests for those scenarios -#### Macro +#### Macro [Macro performance tests](perf/macro) are best written for scenarios where many object instance allocations (or deallocations) are occurring. Operators that create a lot of child subscriptions, or operators that emit new objects like Observables and Subjects are definitely worth creating @@ -162,7 +187,7 @@ protractor protractor.conf.js ``` -#### Micro +#### Micro [Micro performance tests](perf/micro) really only serve to test operations per second. They're quick and easy to develop, and provide a reasonable look into the relative performance of our operators versus prior versions. All operators should have corresponding micro performance tests. @@ -180,7 +205,7 @@ If you wish to run a single micro performance test, you can do so by providing a node perf/micro zip ``` -## Commit Message Guidelines +## Commit Message Guidelines We have very precise rules over how our git commit messages can be formatted. This leads to **more readable messages** that are easy to follow when looking through the **project history**. But also, diff --git a/package.json b/package.json index 831e860caf..0d6c16312a 100644 --- a/package.json +++ b/package.json @@ -78,6 +78,7 @@ "cover_test": "shx rm -rf dist/cjs && tsc typings/main/ambient/es6-shim/index.d.ts src/Rx.ts src/add/observable/of.ts -m commonjs --outDir dist/cjs --sourceMap --target ES5 -d && istanbul cover -x \"spec-js/**/*\" -x \"mocha-setup-node.js\" ./node_modules/mocha/bin/_mocha -- --opts spec/support/default.opts spec-js", "cover_remapping": "remap-istanbul -i coverage/coverage.json -o coverage/coverage-remapped.json && remap-istanbul -i coverage/coverage.json -o coverage/coverage-remapped.lcov -t lcovonly && remap-istanbul -i coverage/coverage.json -o coverage/coverage-remapped -t html", "decision_tree_widget": "cd doc/decision-tree-widget && npm run build && cd ../..", + "doctoc": "doctoc CONTRIBUTING.md", "generate_packages": "node .make-packages.js", "lint_perf": "eslint perf/", "lint_spec": "tslint -c tslint.json spec/*.ts spec/**/*.ts spec/**/**/*.ts", @@ -152,6 +153,7 @@ "commitizen": "^2.7.2", "coveralls": "^2.11.8", "cz-conventional-changelog": "1.1.5", + "doctoc": "^1.0.0", "esdoc": "^0.4.6", "eslint": "^2.4.0", "fs-extra": "^0.26.5",