doc: use consistent new lines

PR-URL: #17722
Reviewed-By: Jon Moss <me@jonathanmoss.me>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>

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.

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

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
 ```

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 <file>` 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

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.