test: fix test-bootstrap-modules to account for workers module

.gitignore

@@ -133,3 +133,5 @@ deps/uv/docs/src/guide/
 deps/v8/gypfiles/Debug/
 deps/v8/gypfiles/Release/
 deps/v8/third_party/eu-strip/
+
+.DS_Store

.travis.yml

@@ -13,7 +13,7 @@ matrix:
       script:
         - make lint
         # Lint the first commit in the PR.
-        - git log $TRAVIS_COMMIT_RANGE --pretty=format:'%h' --no-merges | tail -1 | xargs npx core-validate-commit --no-validate-metadata
+        - \[ -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"
       install:
         - ./configure

BUILDING.md

@@ -52,8 +52,7 @@ which it is attached.
 
 ### Input
 
-Node.js relies on V8 and libuv. Therefore, we adopt a subset of their
-supported platforms.
+Node.js relies on V8 and libuv. We adopt a subset of their supported platforms.
 
 ### Strategy
 
@@ -111,8 +110,8 @@ platforms in production.
   community will only address issues that reproduce on native GNU/Linux
   systems. Issues that only reproduce on WSL should be reported in the
   [WSL issue tracker](https://github.com/Microsoft/WSL/issues). Running the
-  Windows binary (`node.exe`) in WSL is not recommended, and will not work
-  without adjustment (such as stdio redirection).
+  Windows binary (`node.exe`) in WSL is not recommended. It will not work
+  without workarounds such as stdio redirection.
 
 ### Supported toolchains
 
@@ -144,10 +143,8 @@ 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.
 
-*Note:* The forthcoming OpenSSL-1.1.1 will require higher
- version. Please refer
- https://www.openssl.org/docs/man1.1.1/man3/OPENSSL_ia32cap.html for
- details.
+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
 
@@ -216,7 +213,7 @@ $ make test-only
 
 At this point, you are ready to make code changes and re-run the tests.
 
-If you are running tests prior to submitting a Pull Request, the recommended
+If you are running tests before submitting a Pull Request, the recommended
 command is:
 
 ```console
@@ -344,7 +341,7 @@ Prerequisites:
   and tools which can be included in the global `PATH`.
 * The [NetWide Assembler](http://www.nasm.us/), for OpenSSL assembler modules.
   If not installed in the default location, it needs to be manually added
-  to `PATH`. Build with `openssl-no-asm` option does not require this.
+  to `PATH`. A build with the `openssl-no-asm` option does not need this.
 * **Optional** (to build the MSI): the [WiX Toolset v3.11](http://wixtoolset.org/releases/)
   and the [Wix Toolset Visual Studio 2017 Extension](https://marketplace.visualstudio.com/items?itemName=RobMensching.WixToolsetVisualStudio2017Extension).
 
@@ -369,12 +366,10 @@ To test if Node.js was built correctly:
 
 ### Android/Android-based devices (e.g. Firefox OS)
 
-Although these instructions for building on Android are provided, please note
-that Android is not an officially supported platform at this time. Patches to
-improve the Android build are accepted. However, there is no testing on Android
-in the current continuous integration environment. The participation of people
-dedicated and determined to improve Android building, testing, and support is
-encouraged.
+Android is not a supported platform. Patches to improve the Android build are
+welcome. There is no testing on Android in the current continuous integration
+environment. The participation of people dedicated and determined to improve
+Android building, testing, and support is encouraged.
 
 Be sure you have downloaded and extracted
 [Android NDK](https://developer.android.com/tools/sdk/ndk/index.html) before in

COLLABORATOR_GUIDE.md

@@ -100,7 +100,8 @@ As soon as the PR is ready to land, please do so. Landing your own pull requests
 allows other Collaborators to focus on other pull requests. If your pull request
 is still awaiting the [minimum time to land](#waiting-for-approvals), add the
 `author ready` label so other Collaborators know it can land as soon as the time
-ends.
+ends. If instead you wish to land the PR yourself, indicate this intent by using
+the "assign yourself" button, to self-assign the PR.
 
 ## Accepting Modifications
 
@@ -139,30 +140,26 @@ the CI outcome.
 
 ### Consensus Seeking
 
-If there is no disagreement amongst Collaborators, a pull request should be
-landed given appropriate review, a green CI, and the minimum
-[waiting time](#waiting-for-approvals) for a PR. If it is still awaiting the
-[minimum time to land](#waiting-for-approvals), please add the `author ready`
-label to it so it is obvious that the PR can land as soon as the time ends.
-
-Where there is discussion amongst Collaborators, consensus should be sought if
-possible. The lack of consensus may indicate the need to elevate discussion to
-the TSC for resolution.
-
-If any Collaborator objects to a change *without giving any additional
-explanation or context*, and the objecting Collaborator fails to respond to
-explicit requests for explanation or context within a reasonable period of
-time, the objection may be dismissed. Note that this does not apply to
-objections that are explained.
-
-Note that breaking changes (that is, pull requests that require an increase in
-the major version number, known as `semver-major` changes) must be [elevated for
-review by the TSC](#involving-the-tsc). This does not necessarily mean that the
-PR must be put onto the TSC meeting agenda. If multiple TSC members approve
-(`LGTM`) the PR and no Collaborators oppose the PR, it should be landed. Where
-there is disagreement among TSC members or objections from one or more
-Collaborators, `semver-major` pull requests may be put on the TSC meeting
-agenda.
+If there are no objecting Collaborators, a pull request may land if it has the
+needed [approvals](#code-reviews), [CI](#testing-and-ci), and
+[wait time](#waiting-for-approvals). If a pull request meets all requirements
+except the [wait time](#waiting-for-approvals), please add the
+[`author ready`](#author-ready-pull-requests) label.
+
+Where there is disagreement among Collaborators, consensus should be sought if
+possible. If reaching consensus is not possible, a Collaborator may escalate the
+issue to the TSC.
+
+Collaborators should not block a pull request without providing a reason.
+Another Collaborator may ask an objecting Collaborator to explain their
+objection. If the objector is unresponsive, another Collaborator may dismiss the
+objection.
+
+[Breaking changes](#breaking-changes) must receive
+[TSC review](#involving-the-tsc). If two TSC members approve the pull request
+and no Collaborators object, then it may land. If there are objections, a
+Collaborator may apply the `tsc-agenda` label. That will put the pull request on
+the TSC meeting agenda.
 
 #### Helpful resources
 
@@ -190,7 +187,9 @@ Collaborators that previously approved the pull request. If someone disagrees
 with the fast-tracking request, remove the label and leave a comment indicating
 why the pull request should not be fast-tracked. The pull request can be landed
 once two or more Collaborators approve both the pull request and the
-fast-tracking request, and the necessary CI testing is done.
+fast-tracking request, and the necessary CI testing is done. A request to
+fast-track a PR made by a different Collaborator than the pull-request author
+counts as a fast-track approval.
 
 ### Testing and CI
 
@@ -505,12 +504,16 @@ The TSC should serve as the final arbiter where required.
 
 ## Landing Pull Requests
 
+1. Avoid landing PRs that are assigned to someone else. Authors who wish to land
+   their own PRs will self-assign them, or delegate to someone else. If in
+   doubt, ask the assignee whether it is okay to land.
 1. Never use GitHub's green ["Merge Pull Request"][] button. Reasons for not
    using the web interface button:
-   * The merge method will add an unnecessary merge commit.
-   * The squash & merge method can add metadata (the PR #) to the commit title.
-   * If more than one author has contributed to the PR, keep the most recent
-     author when squashing.
+   * The "Create a merge commit" method will add an unnecessary merge commit.
+   * The "Squash and merge" method will add metadata (the PR #) to the commit
+     title. If more than one author has contributed to the PR, squashing will
+     only keep the most recent author.
+   * The "Rebase and merge" method has no way of adding metadata to the commit.
 1. Make sure the CI is done and the result is green. If the CI is not green,
    check for flaky tests and infrastructure failures. Please check if those were
    already reported in the appropriate repository ([node][flaky tests] and
@@ -521,13 +524,12 @@ The TSC should serve as the final arbiter where required.
    present.
 1. Review the commit message to ensure that it adheres to the guidelines
    outlined in the [contributing][] guide.
-1. Add all necessary [metadata](#metadata) to commit messages before landing.
-   See the commit log for examples such as [this
-   one](https://github.com/nodejs/node/commit/b636ba8186) if unsure exactly how
-   to format your commit messages.
+1. Add all necessary [metadata](#metadata) to commit messages before landing. If
+   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.
 
-Check PRs from new contributors to make sure the person's name and email address
-are correct before merging.
+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
 tests. This makes it much easier when bisecting to find a breaking change.
@@ -905,6 +907,7 @@ If you cannot find who to cc for a file, `git shortlog -n -s <file>` may help.
 [`node-core-utils`]: https://github.com/nodejs/node-core-utils
 [backporting guide]: doc/guides/backporting-to-release-lines.md
 [contributing]: ./doc/guides/contributing/pull-requests.md#commit-message-guidelines
+[commit-example]: https://github.com/nodejs/node/commit/b636ba8186
 [flaky tests]: https://github.com/nodejs/node/issues?q=is%3Aopen+is%3Aissue+label%3A%22CI+%2F+flaky+test%22y
 [git-node]: https://github.com/nodejs/node-core-utils/blob/master/docs/git-node.md
 [git-node-metadata]: https://github.com/nodejs/node-core-utils/blob/master/docs/git-node.md#git-node-metadata

CPP_STYLE_GUIDE.md

@@ -2,6 +2,7 @@
 
 ## Table of Contents
 
+* [Guides and References](#guides-and-references)
 * [Formatting](#formatting)
   * [Left-leaning (C++ style) asterisks for pointer declarations](#left-leaning-c-style-asterisks-for-pointer-declarations)
   * [C++ style comments](#c-style-comments)
@@ -25,14 +26,30 @@
   * [Avoid throwing JavaScript errors in C++ methods](#avoid-throwing-javascript-errors-in-c)
     * [Avoid throwing JavaScript errors in nested C++ methods](#avoid-throwing-javascript-errors-in-nested-c-methods)
 
-Unfortunately, the C++ linter (based on
-[Google’s `cpplint`](https://github.com/google/styleguide)), which can be run
-explicitly via `make lint-cpp`, does not currently catch a lot of rules that are
-specific to the Node.js C++ code base. This document explains the most common of
-these rules:
+
+## Guides and References
+
+The Node.js C++ codebase strives to be consistent in its use of language
+features and idioms, as well as have some specific guidelines for the use of
+runtime features.
+
+Coding guidelines are based on the following guides (highest priority first):
+1. This document
+2. The [Google C++ Style Guide][]
+3. The ISO [C++ Core Guidelines][]
+
+In general code should follow the C++ Core Guidelines, unless overridden by the
+Google C++ Style Guide or this document. At the moment these guidelines are
+checked manually by reviewers, with the goal to validate this with automatic
+tools.
 
 ## Formatting
 
+Unfortunately, the C++ linter (based on [Google’s `cpplint`][]), which can be
+run explicitly via `make lint-cpp`, does not currently catch a lot of rules that
+are specific to the Node.js C++ code base. This document explains the most
+common of these rules:
+
 ### Left-leaning (C++ style) asterisks for pointer declarations
 
 `char* buffer;` instead of `char *buffer;`
@@ -175,40 +192,39 @@ class FancyContainer {
 
 ### Use `nullptr` instead of `NULL` or `0`
 
-What it says in the title.
+Further reading in the [C++ Core Guidelines][ES.47].
 
 ### Ownership and Smart Pointers
 
-"Smart" pointers are classes that act like pointers, e.g.
-by overloading the `*` and `->` operators. Some smart pointer types can be
-used to automate ownership bookkeeping, to ensure these responsibilities are
-met. `std::unique_ptr` is a smart pointer type introduced in C++11, which
-expresses exclusive ownership of a dynamically allocated object; the object
-is deleted when the `std::unique_ptr` goes out of scope. It cannot be
-copied, but can be moved to represent ownership transfer.
-`std::shared_ptr` is a smart pointer type that expresses shared ownership of a
-dynamically allocated object. `std::shared_ptr`s can be copied; ownership
-of the object is shared among all copies, and the object
-is deleted when the last `std::shared_ptr` is destroyed.
-
-Prefer to use `std::unique_ptr` to make ownership
-transfer explicit. For example:
+* [R.20]: Use `std::unique_ptr` or `std::shared_ptr` to represent ownership
+* [R.21]: Prefer `unique_ptr` over `shared_ptr` unless you need to share
+  ownership
+
+Use `std::unique_ptr` to make ownership transfer explicit. For example:
 
 ```cpp
 std::unique_ptr<Foo> FooFactory();
 void FooConsumer(std::unique_ptr<Foo> ptr);
 ```
 
-Never use `std::auto_ptr`. Instead, use `std::unique_ptr`.
+Since `std::unique_ptr` has only move semantics, passing one by value transfers
+ownership to the callee and invalidates the caller's instance.
+
+Don't use `std::auto_ptr`, it is deprecated ([Reference][cppref_auto_ptr]).
 
 ## Others
 
 ### Type casting
 
-- Always avoid C-style casts (`(type)value`)
-- `dynamic_cast` does not work because RTTI is not enabled
-- Use `static_cast` for casting whenever it works
-- `reinterpret_cast` is okay if `static_cast` is not appropriate
+- Use `static_cast<T>` if casting is required, and it is valid
+- Use `reinterpret_cast` only when it is necessary
+- Avoid C-style casts (`(type)value`)
+- `dynamic_cast` does not work because Node.js is built without
+  [Run Time Type Information][]
+
+Further reading:
+* [ES.48]: Avoid casts
+* [ES.49]: If you must use a cast, use a named cast
 
 ### Using `auto`
 
@@ -299,9 +315,25 @@ exports.foo = function(str) {
 
 #### Avoid throwing JavaScript errors in nested C++ methods
 
-When you have to throw the errors from C++, try to do it at the top level and
-not inside of nested calls.
+When you need to throw a JavaScript exception from C++ (i.e.
+`isolate()->ThrowException()`) prefer to do it as close to the return to JS as
+possible, and not inside of nested C++ calls. Since this changes the JS
+execution state doing it closest to where it is consumed reduces the chances of
+side effects.
+
+Node.js is built [without C++ exception handling][], so code using `throw` or
+even `try` and `catch` **will** break.
 
-Using C++ `throw` is not allowed.
 
+[C++ Core Guidelines]: http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
+[Google C++ Style Guide]: https://google.github.io/styleguide/cppguide.html
+[Google’s `cpplint`]: https://github.com/google/styleguide
 [errors]: https://github.com/nodejs/node/blob/master/doc/guides/using-internal-errors.md
+[ES.47]: http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-nullptr
+[ES.48]: http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-casts
+[ES.49]: http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-casts-named
+[R.20]: http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-owner
+[R.21]: http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-unique
+[Run Time Type Information]: https://en.wikipedia.org/wiki/Run-time_type_information
+[cppref_auto_ptr]: https://en.cppreference.com/w/cpp/memory/auto_ptr
+[without C++ exception handling]: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_exceptions.html#intro.using.exception.no

README.md

@@ -159,23 +159,17 @@ source and a list of supported platforms.
 
 ## Security
 
-Security flaws in Node.js should be reported by emailing [email protected].
-Please do not disclose security bugs publicly until they have been handled by
-the security team.
+If you find a security vulnerability in Node.js, please report it to
+[email protected]. Please withhold public disclosure until after the security
+team has addressed the vulnerability.
 
-Your email will be acknowledged within 24 hours, and you will receive a more
-detailed response to your email within 48 hours indicating the next steps in
-handling your report.
+The security team will acknowledge your email within 24 hours. You will receive
+a more detailed response within 48 hours.
 
-There are no hard and fast rules to determine if a bug is worth reporting as
-a security issue. The general rule is an issue worth reporting should allow an
-attacker to compromise the confidentiality, integrity, or availability of the
-Node.js application or its system for which the attacker does not already have
-the capability.
-
-To illustrate the point, here are some examples of past issues and what the
-Security Response Team thinks of them. When in doubt, however, please do send
-us a report nonetheless.
+There are no hard and fast rules to determine if a bug is worth reporting as a
+security issue. Here are some examples of past issues and what the Security
+Response Team thinks of them. When in doubt, please do send us a report
+nonetheless.
 
 
 ### Public disclosure preferred
@@ -214,9 +208,7 @@ When in doubt, please do send us a report.
 
 ## Current Project Team Members
 
-The Node.js project team comprises a group of core collaborators and a sub-group
-that forms the _Technical Steering Committee_ (TSC) which governs the project.
-For more information about the governance of the Node.js project, see
+For information about the governance of the Node.js project, see
 [GOVERNANCE.md](./GOVERNANCE.md).
 
 ### TSC (Technical Steering Committee)
@@ -593,7 +585,7 @@ Node.js releases are signed with one of the following GPG keys:
 * **Rod Vagg** <[email protected]>
 `DD8F2338BAE7501E3DD5AC78C273792F7D83545D`
 
-The full set of trusted release keys can be imported by running:
+To import the full set of trusted release keys:
 
 ```shell
 gpg --keyserver pool.sks-keyservers.net --recv-keys 94AE36675C464D64BAFA68DD7434390BDBE9B9C5
@@ -609,7 +601,7 @@ gpg --keyserver pool.sks-keyservers.net --recv-keys DD8F2338BAE7501E3DD5AC78C273
 See the section above on [Verifying Binaries](#verifying-binaries) for how to
 use these keys to verify a downloaded file.
 
-Previous releases may also have been signed with one of the following GPG keys:
+Other keys used to sign some previous releases:
 
 * **Chris Dickinson** <[email protected]>
 `9554F04D7259F04124DE6B476D5A82AC7E37093B`