Release proposal: v11.2

.eslintrc.js

@@ -17,7 +17,7 @@ Module._findPath = (request, paths, isMain) => {
   if (!r && hacks.includes(request)) {
     try {
       return require.resolve(`./tools/node_modules/${request}`);
-    } catch (err) {
+    } catch {
       return require.resolve(
         `./tools/node_modules/eslint/node_modules/${request}`);
     }
@@ -212,7 +212,7 @@ module.exports = {
     'no-unsafe-finally': 'error',
     'no-unsafe-negation': 'error',
     'no-unused-labels': 'error',
-    'no-unused-vars': ['error', { args: 'none' }],
+    'no-unused-vars': ['error', { args: 'none', caughtErrors: 'all' }],
     'no-use-before-define': ['error', {
       classes: true,
       functions: false,

.travis.yml

@@ -4,14 +4,21 @@ cache: ccache
 os: linux
 matrix:
   include:
+    - name: "First commit message adheres to guidelines at <a href=\"https://goo.gl/p2fr5Q\">https://goo.gl/p2fr5Q</a>"
+      if: type = pull_request
+      language: node_js
+      node_js: "node"
+      script:
+        - if [ "${TRAVIS_PULL_REQUEST}" != "false" ]; then
+            bash -x tools/lint-pr-commit-message.sh ${TRAVIS_PULL_REQUEST};
+          fi
     - name: "Linter"
-      node_js: "latest"
+      language: node_js
+      node_js: "node"
       env:
         - NODE=$(which node)
       script:
         - make lint
-        # Lint the first commit in the PR.
-        - \[ -z "$TRAVIS_COMMIT_RANGE" \] || (echo -e '\nLinting the commit message according to the guidelines at https://goo.gl/p2fr5Q\n' && git log $TRAVIS_COMMIT_RANGE --pretty=format:'%h' --no-merges | tail -1 | xargs npx -q core-validate-commit --no-validate-metadata)
     - name: "Test Suite"
       addons:
         apt:

BUILDING.md

@@ -70,8 +70,7 @@ There are three support tiers:
 ### Supported platforms
 
 The community does not build or test against end-of-life distributions (EoL).
-Thus, we do not recommend that you use Node.js on end-of-life or unsupported
-platforms in production.
+For production applications, run Node.js on supported platforms only.
 
 | System       | Support type | Version                         | Architectures    | Notes                         |
 | ------------ | ------------ | ------------------------------- | ---------------- | ----------------------------- |
@@ -96,8 +95,8 @@ platforms in production.
   by Joyent. SmartOS images >= 16.4 are not supported because
   GCC 4.8 runtime libraries are not available in their pkgsrc repository
 
-<em id="fn2">2</em>: Tier 1 support for building on Windows is only on 64 bit
-  hosts. Support is experimental for 32 bit hosts.
+<em id="fn2">2</em>: Tier 1 support for building on Windows is only on 64-bit
+  hosts. Support is experimental for 32-bit hosts.
 
 <em id="fn3">3</em>: On Windows, running Node.js in Windows terminal emulators
   like `mintty` requires the usage of [winpty](https://github.com/rprichard/winpty)
@@ -115,7 +114,7 @@ platforms in production.
 
 ### Supported toolchains
 
-Depending on host platform, the selection of toolchains may vary.
+Depending on the host platform, the selection of toolchains may vary.
 
 #### Unix
 
@@ -127,29 +126,28 @@ Depending on host platform, the selection of toolchains may vary.
 
 #### Windows
 
-* Visual Studio 2017 with the Windows 10 SDK on a 64 bit host.
+* Visual Studio 2017 with the Windows 10 SDK on a 64-bit host.
 
 #### OpenSSL asm support
 
-OpenSSL-1.1.0 requires the following asssembler version for use of asm
+OpenSSL-1.1.0 requires the following assembler version for use of asm
 support on x86_64 and ia32.
 
 * gas (GNU assembler) version 2.23 or higher
-* xcode version 5.0 or higher
+* Xcode version 5.0 or higher
 * llvm version 3.3 or higher
 * nasm version 2.10 or higher in Windows
 
-Otherwise `configure` will fail with an error. This can be avoided by
-either providing a newer assembler as per the list above or by
-using the `--openssl-no-asm` flag.
+If compiling without one of the above, use `configure` with the
+`--openssl-no-asm` flag. Otherwise, `configure` will fail.
 
 The forthcoming OpenSSL-1.1.1 will have different requirements. Please refer to
  https://www.openssl.org/docs/man1.1.1/man3/OPENSSL_ia32cap.html for details.
 
 ## Building Node.js on supported platforms
 
-*Note:* All prerequisites can be easily installed by following
-[this bootstrapping guide](https://github.com/nodejs/node/blob/master/tools/bootstrap/README.md).
+The [bootstrapping guide](https://github.com/nodejs/node/blob/master/tools/bootstrap/README.md)
+explains how to install all prerequisites.
 
 ### Unix/macOS
 
@@ -160,7 +158,7 @@ The forthcoming OpenSSL-1.1.1 will have different requirements. Please refer to
 * Python 2.6 or 2.7
 * GNU Make 3.81 or newer
 
-On macOS, you will need to install the `Xcode Command Line Tools` by running
+On macOS, install the `Xcode Command Line Tools` by running
 `xcode-select --install`. Alternatively, if you already have the full Xcode
 installed, you can find them under the menu `Xcode -> Open Developer Tool ->
 More Developer Tools...`. This step will install `clang`, `clang++`, and
@@ -181,13 +179,9 @@ $ ./configure
 $ make -j4
 ```
 
-Running `make` with the `-j4` flag will cause it to run 4 compilation jobs
-concurrently which may significantly reduce build time. The number after `-j`
-can be changed to best suit the number of processor cores on your machine. If
-you run into problems running `make` with concurrency, try running it without
-the `-j4` flag. See the
-[GNU Make Documentation](https://www.gnu.org/software/make/manual/html_node/Parallel.html)
-for more information.
+The `-j4` option will cause `make` to run 4 simultaneous compilation jobs which
+may reduce build time. For more information, see the
+[GNU Make Documentation](https://www.gnu.org/software/make/manual/html_node/Parallel.html).
 
 Note that the above requires that `python` resolve to Python 2.6 or 2.7
 and not a newer version.
@@ -365,7 +359,7 @@ These core dumps are useful for debugging when provided with the
 corresponding original debug binary and system information.
 
 Reading the core dump requires `gdb` built on the same platform the core dump
-was captured on (i.e. 64 bit `gdb` for `node` built on a 64 bit system, Linux
+was captured on (i.e. 64-bit `gdb` for `node` built on a 64-bit system, Linux
 `gdb` for `node` built on Linux) otherwise you will get errors like
 `not in executable format: File format not recognized`.
 
@@ -484,7 +478,7 @@ $ ./configure --without-intl
 $ pkg-config --modversion icu-i18n && ./configure --with-intl=system-icu
 ```
 
-If you are cross compiling, your `pkg-config` must be able to supply a path
+If you are cross-compiling, your `pkg-config` must be able to supply a path
 that works for both your host and target environments.
 
 #### Build with a specific ICU:
@@ -532,7 +526,7 @@ This version of Node.js does not support FIPS.
 ## Building Node.js with external core modules
 
 It is possible to specify one or more JavaScript text files to be bundled in
-the binary as builtin modules when building Node.js.
+the binary as built-in modules when building Node.js.
 
 ### Unix/macOS
 

CHANGELOG.md

@@ -1,11 +1,5 @@
 # Node.js Changelog
 
-<!--lint disable maximum-line-length-->
-
-To make the changelog easier to both use and manage, it has been split into
-multiple files organized according to significant major and minor Node.js
-release lines.
-
 Select a Node.js version below to view the changelog history:
 
 * [Node.js 11](doc/changelogs/CHANGELOG_V11.md) - **Current**
@@ -24,6 +18,7 @@ Select a Node.js version below to view the changelog history:
 Please use the following table to find the changelog for a specific Node.js
 release.
 
+<!--lint disable maximum-line-length-->
 <table>
 <tr>
   <th title="Current"><a href="doc/changelogs/CHANGELOG_V11.md">11</a><sup>Current</sup></th>
@@ -33,7 +28,8 @@ release.
 </tr>
 <tr>
     <td valign="top">
-<b><a href="doc/changelogs/CHANGELOG_V11.md#11.1.0">11.1.0</a></b><br/>
+<b><a href="doc/changelogs/CHANGELOG_V11.md#11.2.0">11.2.0</a></b><br/>
+<a href="doc/changelogs/CHANGELOG_V11.md#11.1.0">11.1.0</a><br/>
 <a href="doc/changelogs/CHANGELOG_V11.md#11.0.0">11.0.0</a><br/>
     </td>
     <td valign="top">
@@ -129,10 +125,9 @@ release.
 
 ### Notes
 
-* Release streams marked with `LTS` are currently covered by the
-  [Node.js Long Term Support plan](https://github.com/nodejs/Release).
-* Release versions displayed in **bold** text represent the most
-  recent actively supported release.
+* The [Node.js Long Term Support plan](https://github.com/nodejs/Release) covers
+  LTS releases.
+* Release versions in **bold** text are the most recent supported releases.
 
 ----
 ----

CODE_OF_CONDUCT.md

@@ -1,8 +1,4 @@
 # Code of Conduct
 
-The Node.js Code of Conduct document has moved to
-https://github.com/nodejs/admin/blob/master/CODE_OF_CONDUCT.md. Please update
-links to this document accordingly.
-
-The Node.js Moderation policy can be found at
-https://github.com/nodejs/admin/blob/master/Moderation-Policy.md
+* [Node.js Code of Conduct](https://github.com/nodejs/admin/blob/master/CODE_OF_CONDUCT.md)
+* [Node.js Moderation Policy](https://github.com/nodejs/admin/blob/master/Moderation-Policy.md)

COLLABORATOR_GUIDE.md

@@ -3,7 +3,6 @@
 ## Contents
 
 * [Issues and Pull Requests](#issues-and-pull-requests)
-  - [Managing Issues and Pull Requests](#managing-issues-and-pull-requests)
   - [Welcoming First-Time Contributors](#welcoming-first-time-contributors)
   - [Closing Issues and Pull Requests](#closing-issues-and-pull-requests)
   - [Author ready pull requests](#author-ready-pull-requests)
@@ -28,7 +27,7 @@
   - [Using `git-node`](#using-git-node)
   - [Technical HOWTO](#technical-howto)
   - [Troubleshooting](#troubleshooting)
-  - [I Just Made a Mistake](#i-just-made-a-mistake)
+  - [I Made a Mistake](#i-made-a-mistake)
   - [Long Term Support](#long-term-support)
     - [What is LTS?](#what-is-lts)
     - [How does LTS work?](#how-does-lts-work)
@@ -38,24 +37,16 @@
     - [How is an LTS release cut?](#how-is-an-lts-release-cut)
 * [Who to CC in the issue tracker](#who-to-cc-in-the-issue-tracker)
 
-This document contains information for Collaborators of the Node.js
-project regarding managing the project's code, documentation, and issue tracker.
-
-Collaborators should be familiar with the guidelines for new
-contributors in [CONTRIBUTING.md](./CONTRIBUTING.md) and also
-understand the project governance model as outlined in
-[GOVERNANCE.md](./GOVERNANCE.md).
+This document explains how Collaborators manage the Node.js project.
+Collaborators should understand the
+[guidelines for new contributors](CONTRIBUTING.md) and the
+[project governance model](GOVERNANCE.md).
 
 ## Issues and Pull Requests
 
-### Managing Issues and Pull Requests
-
-Collaborators should take full responsibility for managing issues and pull
-requests they feel qualified to handle. Make sure this is done while being
-mindful of these guidelines, the opinions of other Collaborators, and guidance
-of the [TSC][]. They may also notify other qualified parties for more input on
-an issue or a pull request.
-See [Who to CC in the issue tracker](#who-to-cc-in-the-issue-tracker).
+Mind these guidelines, the opinions of other Collaborators, and guidance of the
+[TSC][]. Notify other qualified parties for more input on an issue or a pull
+request. See [Who to CC in the issue tracker](#who-to-cc-in-the-issue-tracker).
 
 ### Welcoming First-Time Contributors
 
@@ -497,7 +488,7 @@ This should be done where a pull request:
 
 Assign the `tsc-review` label or @-mention the
 `@nodejs/tsc` GitHub team if you want to elevate an issue to the [TSC][].
-Do not use the GitHub UI on the right hand side to assign to
+Do not use the GitHub UI on the right-hand side to assign to
 `@nodejs/tsc` or request a review from `@nodejs/tsc`.
 
 The TSC should serve as the final arbiter where required.
@@ -528,7 +519,7 @@ The TSC should serve as the final arbiter where required.
    you are unsure exactly how to format the commit messages, use the commit log
    as a reference. See [this commit][commit-example] as an example.
 
-For PRs from first time contributors, be [welcoming](#welcoming-first-time-contributors).
+For PRs from first-time contributors, be [welcoming](#welcoming-first-time-contributors).
 Also, verify that their git settings are to their liking.
 
 All commits should be self-contained, meaning every commit should pass all
@@ -747,7 +738,7 @@ make -j4 test
 git push upstream master
 ```
 
-### I Just Made a Mistake
+### I Made a Mistake
 
 * Ping a TSC member.
 * `#node-dev` on freenode

CONTRIBUTING.md

@@ -1,18 +1,5 @@
 # Contributing to Node.js
 
-Contributions to Node.js include code, documentation, answering user questions,
-running the project's infrastructure, and advocating for all types of Node.js
-users.
-
-The Node.js project welcomes all contributions from anyone willing to work in
-good faith with other contributors and the community. No contribution is too
-small and all contributions are valued.
-
-This guide explains the process for contributing to the Node.js project's core
-`nodejs/node` GitHub Repository and describes what to expect at each step.
-
-## Contents
-
 * [Code of Conduct](#code-of-conduct)
 * [Issues](#issues)
 * [Pull Requests](#pull-requests)
@@ -22,16 +9,12 @@ This guide explains the process for contributing to the Node.js project's core
 
 The Node.js project has a
 [Code of Conduct](https://github.com/nodejs/admin/blob/master/CODE_OF_CONDUCT.md)
-that *all* contributors are expected to follow. This code describes the
-*minimum* behavior expectations for all contributors.
+to which all contributors must adhere.
 
 See [details on our policy on Code of Conduct](./doc/guides/contributing/coc.md).
 
 ## [Issues](./doc/guides/contributing/issues.md)
 
-Issues in `nodejs/node` are the primary means by which bug reports and
-general discussions are made.
-
 * [How to Contribute in Issues](./doc/guides/contributing/issues.md#how-to-contribute-in-issues)
 * [Asking for General Help](./doc/guides/contributing/issues.md#asking-for-general-help)
 * [Discussing non-technical topics](./doc/guides/contributing/issues.md#discussing-non-technical-topics)
@@ -41,14 +24,11 @@ general discussions are made.
 
 ## [Pull Requests](./doc/guides/contributing/pull-requests.md)
 
-Pull Requests are the way concrete changes are made to the code, documentation,
-dependencies, and tools contained in the `nodejs/node` repository.
-
 * [Dependencies](./doc/guides/contributing/pull-requests.md#dependencies)
 * [Setting up your local environment](./doc/guides/contributing/pull-requests.md#setting-up-your-local-environment)
 * [The Process of Making Changes](./doc/guides/contributing/pull-requests.md#the-process-of-making-changes)
 * [Reviewing Pull Requests](./doc/guides/contributing/pull-requests.md#reviewing-pull-requests)
-* [Additional Notes](./doc/guides/contributing/pull-requests.md#additional-notes)
+* [Notes](./doc/guides/contributing/pull-requests.md#notes)
 
 <a id="developers-certificate-of-origin"></a>
 ## Developer's Certificate of Origin 1.1

GOVERNANCE.md

@@ -45,7 +45,7 @@ be accepted unless:
 
 * Discussions and/or additional changes result in no Collaborators objecting to
   the change. Previously-objecting Collaborators do not necessarily have to
-  sign-off on the change, but they should not be opposed to it.
+  sign off on the change, but they should not be opposed to it.
 * The change is escalated to the TSC and the TSC votes to approve the change.
   This should only happen if disagreements between Collaborators cannot be
   resolved through discussion.
@@ -123,8 +123,8 @@ The meeting chair is responsible for ensuring that minutes are taken and that a
 pull request with the minutes is submitted after the meeting.
 
 Due to the challenges of scheduling a global meeting with participants in
-several timezones, the TSC will seek to resolve as many agenda items as possible
-outside of meetings using
+several time zones, the TSC will seek to resolve as many agenda items as
+possible outside of meetings using
 [the TSC issue tracker](https://github.com/nodejs/TSC/issues). The process in
 the issue tracker is:
 
@@ -196,7 +196,7 @@ completed within a month after the nomination is accepted.
 
 ## Consensus Seeking Process
 
-The TSC follows a [Consensus Seeking][] decision making model as described by
+The TSC follows a [Consensus Seeking][] decision-making model as described by
 the [TSC Charter][].
 
 [collaborators-discussions]: https://github.com/orgs/nodejs/teams/collaborators/discussions