diff --git a/doc/guides/maintaining-V8.md b/doc/guides/maintaining-V8.md index 887c9a8766035a..d45fa072074aee 100644 --- a/doc/guides/maintaining-V8.md +++ b/doc/guides/maintaining-V8.md @@ -275,6 +275,7 @@ Original commit message: Refs: https://github.com/v8/v8/commit/a51f429772d1e796744244128c9feeab4c26a854 PR-URL: https://github.com/nodejs/node/pull/7833 ``` + * Open a PR against the `v6.x-staging` branch in the Node.js repo. Launch the normal and [V8 CI] using the Node.js CI system. We only needed to backport to `v6.x` as the other LTS branches weren't affected by this bug. diff --git a/doc/guides/writing-and-running-benchmarks.md b/doc/guides/writing-and-running-benchmarks.md index 75435daf394898..22e235df323d52 100644 --- a/doc/guides/writing-and-running-benchmarks.md +++ b/doc/guides/writing-and-running-benchmarks.md @@ -144,6 +144,7 @@ arrays/zero-int.js n=25 type=Buffer: 90.49906662339653 ``` It is possible to execute more groups by adding extra process arguments. + ```console $ node benchmark/run.js arrays buffers ``` @@ -439,6 +440,7 @@ function main(conf) { ``` Supported options keys are: + * `port` - defaults to `common.PORT` * `path` - defaults to `/` * `connections` - number of concurrent connections to use, defaults to 100 diff --git a/doc/guides/writing-tests.md b/doc/guides/writing-tests.md index 1fa2b3c558f876..b2cd8ed8b2f165 100644 --- a/doc/guides/writing-tests.md +++ b/doc/guides/writing-tests.md @@ -306,12 +306,14 @@ the upstream project, send another PR here to update Node.js accordingly. Be sure to update the hash in the URL following `WPT Refs:`. ## C++ Unit test + C++ code can be tested using [Google Test][]. Most features in Node.js can be tested using the methods described previously in this document. But there are cases where these might not be enough, for example writing code for Node.js that will only be called when Node.js is embedded. ### Adding a new test + The unit test should be placed in `test/cctest` and be named with the prefix `test` followed by the name of unit being tested. For example, the code below would be placed in `test/cctest/test_env.cc`: @@ -345,18 +347,21 @@ static void at_exit_callback(void* arg) { ``` Next add the test to the `sources` in the `cctest` target in node.gyp: + ```console 'sources': [ 'test/cctest/test_env.cc', ... ], ``` + Note that the only sources that should be included in the cctest target are actual test or helper source files. There might be a need to include specific object files that are compiled by the `node` target and this can be done by adding them to the `libraries` section in the cctest target. The test can be executed by running the `cctest` target: + ```console $ make cctest ``` diff --git a/doc/onboarding-extras.md b/doc/onboarding-extras.md index a010d8fef1fe41..9b00b2cecfcbb3 100644 --- a/doc/onboarding-extras.md +++ b/doc/onboarding-extras.md @@ -47,7 +47,6 @@ When things need extra attention, are controversial, or `semver-major`: If you cannot find who to cc for a file, `git shortlog -n -s ` may help. - ## Labels ### By Subsystem @@ -64,7 +63,6 @@ part(s) of the codebase it touches. There may be more than one subsystem valid for any particular issue / PR. - ### General Please use these when possible / appropriate @@ -136,7 +134,6 @@ need to be attached anymore, as only important bugfixes will be included. * `arm`, `mips`, `s390`, `ppc` * No x86{_64}, since that is the implied default - ## Updating Node.js from Upstream * `git remote add upstream git://github.com/nodejs/node.git` @@ -147,7 +144,6 @@ to update from nodejs/node: * `git remote update -p` OR `git fetch --all` (I prefer the former) * `git merge --ff-only upstream/master` (or `REMOTENAME/BRANCH`) - ## best practices * commit often, out to your github fork (origin), open a PR diff --git a/doc/onboarding.md b/doc/onboarding.md index 37e250d558c10e..1491b5ee9e4e1a 100644 --- a/doc/onboarding.md +++ b/doc/onboarding.md @@ -107,6 +107,7 @@ onboarding session. [here](https://github.com/nodejs/TSC/blob/master/Moderation-Policy.md). ## Reviewing PRs + * The primary goal is for the codebase to improve. * Secondary (but not far off) is for the person submitting code to succeed. A pull request from a new contributor is an opportunity to grow the community.