nodejs · kunalspathak · May 18, 2017 · Apr 26, 2017 · Apr 25, 2017 · Apr 24, 2017
diff --git a/.eslintrc.yaml b/.eslintrc.yaml
@@ -97,6 +97,7 @@ rules:
   eol-last: 2
   func-call-spacing: 2
   func-name-matching: 2
+  func-style: [2, declaration, {allowArrowFunctions: true}]
   indent: [2, 2, {ArrayExpression: first,
                   CallExpression: {arguments: first},
                   MemberExpression: 1,
@@ -105,7 +106,10 @@ rules:
   key-spacing: [2, {mode: minimum}]
   keyword-spacing: 2
   linebreak-style: [2, unix]
-  max-len: [2, {code: 80, ignoreUrls: true, tabWidth: 2}]
+  max-len: [2, {code: 80,
+                ignoreRegExpLiterals: true,
+                ignoreUrls: true,
+                tabWidth: 2}]
   new-parens: 2
   no-mixed-spaces-and-tabs: 2
   no-multiple-empty-lines: [2, {max: 2, maxEOF: 0, maxBOF: 0}]

diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
@@ -13,7 +13,7 @@ Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md
 - [ ] `make -j4 test` (UNIX), or `vcbuild test` (Windows) passes
 - [ ] tests and/or benchmarks are included
 - [ ] documentation is changed or added
-- [ ] commit message follows [commit guidelines](https://github.com/nodejs/node/blob/master/CONTRIBUTING.md#commit-guidelines)
+- [ ] commit message follows [commit guidelines](https://github.com/nodejs/node/blob/master/CONTRIBUTING.md#commit-message-guidelines)
 
 ##### Affected core subsystem(s)
 <!-- Provide affected core subsystem(s) (like doc, cluster, crypto, etc). -->
diff --git a/.gitignore b/.gitignore
@@ -34,6 +34,7 @@ node_g
 .benchmark_reports
 icu_config.gypi
 .eslintcache
+node_trace.*.log
 
 /out
 

diff --git a/BUILDING.md b/BUILDING.md
@@ -37,11 +37,11 @@ Support is divided into three tiers:
 |--------------|--------------|----------------------------------|----------------------|------------------|
 | GNU/Linux    | Tier 1       | kernel >= 2.6.18, glibc >= 2.5   | x86, x64, arm, arm64 |                  |
 | macOS        | Tier 1       | >= 10.10                         | x64                  |                  |
-| Windows      | Tier 1       | >= Windows 7 or >= Windows2008R2 | x86, x64             |                  |
+| Windows      | Tier 1       | >= Windows 7 / 2008 R2           | x86, x64             | vs2015 or vs2017 |
 | SmartOS      | Tier 2       | >= 15 < 16.4                     | x86, x64             | see note1        |
 | FreeBSD      | Tier 2       | >= 10                            | x64                  |                  |
-| GNU/Linux    | Tier 2       | kernel >= 3.13.0, glibc >= 2.19  | ppc64le              |                  |
-| AIX          | Tier 2       | >= 7.1 TL04                      | ppc64be              |                  |
+| GNU/Linux    | Tier 2       | kernel >= 3.13.0, glibc >= 2.19  | ppc64le >=power8     |                  |
+| AIX          | Tier 2       | >= 7.1 TL04                      | ppc64be >=power7     |                  |
 | GNU/Linux    | Tier 2       | kernel >= 3.10, glibc >= 2.17    | s390x                |                  |
 | macOS        | Experimental | >= 10.8 < 10.10                  | x64                  | no test coverage |
 | Linux (musl) | Experimental | musl >= 1.0                      | x64                  |                  |
@@ -123,15 +123,6 @@ To run the tests:
 $ make test
 ```
 
-To run the npm test suite:
-
-*note: to run the suite on node v4 or earlier you must first*
-*run `make install`*
-
-```console
-$ make test-npm
-```
-
 To build the documentation:
 
 This will build Node.js first (if necessary) and then use it to build the docs:
@@ -175,6 +166,8 @@ Prerequisites:
   * [Visual Studio 2015 Update 3](https://www.visualstudio.com/), all editions
     including the Community edition (remember to select
     "Common Tools for Visual C++ 2015" feature during installation).
+  * [Visual Studio 2017](https://www.visualstudio.com/downloads/), any edition (including the Build Tools SKU).
+    __Required Components:__ "MSbuild", "VC++ 2017 v141 toolset" and one of the Windows SDKs (10 or 8.1).
 * Basic Unix tools required for some tests,
   [Git for Windows](http://git-scm.com/download/win) includes Git Bash
   and tools which can be included in the global `PATH`.

diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -28,7 +28,8 @@ release.
 </tr>
 <tr>
     <td valign="top">
-<b><a href="doc/changelogs/CHANGELOG_V7.md#7.9.0">7.9.0</a></b><br/>
+<b><a href="doc/changelogs/CHANGELOG_V7.md#7.10.0">7.10.0</a></b><br/>
+<a href="doc/changelogs/CHANGELOG_V7.md#7.9.0">7.9.0</a><br/>
 <a href="doc/changelogs/CHANGELOG_V7.md#7.8.0">7.8.0</a><br/>
 <a href="doc/changelogs/CHANGELOG_V7.md#7.7.4">7.7.4</a><br/>
 <a href="doc/changelogs/CHANGELOG_V7.md#7.7.3">7.7.3</a><br/>
@@ -45,7 +46,8 @@ release.
 <a href="doc/changelogs/CHANGELOG_V7.md#7.0.0">7.0.0</a><br/>
     </td>
   <td valign="top">
-<b><a href="doc/changelogs/CHANGELOG_V6.md#6.10.2">6.10.2</a></b><br/>
+<b><a href="doc/changelogs/CHANGELOG_V6.md#6.10.3">6.10.3</a></b><br/>
+<a href="doc/changelogs/CHANGELOG_V6.md#6.10.2">6.10.2</a><br/>
 <a href="doc/changelogs/CHANGELOG_V6.md#6.10.1">6.10.1</a><br/>
 <a href="doc/changelogs/CHANGELOG_V6.md#6.10.0">6.10.0</a><br/>
 <a href="doc/changelogs/CHANGELOG_V6.md#6.9.5">6.9.5</a><br/>
@@ -89,7 +91,8 @@ release.
 <a href="doc/changelogs/CHANGELOG_V5.md#5.0.0">5.0.0</a><br/>
   </td>
   <td valign="top">
-<b><a href="doc/changelogs/CHANGELOG_V4.md#4.8.2">4.8.2</a></b><br/>
+<b><a href="doc/changelogs/CHANGELOG_V4.md#4.8.3">4.8.3</a></b><br/>
+<a href="doc/changelogs/CHANGELOG_V4.md#4.8.2">4.8.2</a><br/>
 <a href="doc/changelogs/CHANGELOG_V4.md#4.8.1">4.8.1</a><br/>
 <a href="doc/changelogs/CHANGELOG_V4.md#4.8.0">4.8.0</a><br/>
 <a href="doc/changelogs/CHANGELOG_V4.md#4.7.3">4.7.3</a><br/>

diff --git a/COLLABORATOR_GUIDE.md b/COLLABORATOR_GUIDE.md
@@ -4,14 +4,15 @@
 
 * [Issues and Pull Requests](#issues-and-pull-requests)
 * [Accepting Modifications](#accepting-modifications)
- - [Internal vs. Public API](#internal-vs-public-api)
- - [Breaking Changes](#breaking-changes)
- - [Deprecations](#deprecations)
- - [Involving the CTC](#involving-the-ctc)
+   - [Useful CI Jobs](#useful-ci-jobs)
+   - [Internal vs. Public API](#internal-vs-public-api)
+   - [Breaking Changes](#breaking-changes)
+   - [Deprecations](#deprecations)
+   - [Involving the CTC](#involving-the-ctc)
 * [Landing Pull Requests](#landing-pull-requests)
- - [Technical HOWTO](#technical-howto)
- - [I Just Made a Mistake](#i-just-made-a-mistake)
- - [Long Term Support](#long-term-support)
+   - [Technical HOWTO](#technical-howto)
+   - [I Just Made a Mistake](#i-just-made-a-mistake)
+   - [Long Term Support](#long-term-support)
 
 This document contains information for Collaborators of the Node.js
 project regarding maintaining the code, documentation and issues.
@@ -87,6 +88,27 @@ All pull requests that modify executable code should be subjected to
 continuous integration tests on the
 [project CI server](https://ci.nodejs.org/).
 
+#### Useful CI Jobs
+
+* [`node-test-pull-request`](https://ci.nodejs.org/job/node-test-pull-request/)
+is the standard CI run we do to check Pull Requests. It triggers `node-test-commit`,
+which runs the `build-ci` and `test-ci` targets on all supported platforms.
+
+* [`node-test-linter`](https://ci.nodejs.org/job/node-test-linter/)
+only runs the linter targets, which is useful for changes that only affect comments
+or documentation.
+
+* [`citgm-smoker`](https://ci.nodejs.org/job/citgm-smoker/)
+uses [`CitGM`](https://github.com/nodejs/citgm) to allow you to run `npm install && npm test`
+on a large selection of common modules. This is useful to check whether a
+change will cause breakage in the ecosystem. To test Node.JS ABI changes
+you can run [`citgm-abi-smoker`](https://ci.nodejs.org/job/citgm-abi-smoker/).
+
+* [`node-stress-single-test`](https://ci.nodejs.org/job/node-stress-single-test/)
+is designed to allow one to run a group of tests over and over on a specific
+platform to confirm that the test is reliable.
+
+
 ### Internal vs. Public API
 
 Due to the nature of the JavaScript language, it can often be difficult to
@@ -230,6 +252,13 @@ not can often be based on many complex factors that are not easily codified. It
 is also possible that the breaking commit can be labeled retroactively as a
 semver-major change that will not be backported to Current or LTS branches.
 
+##### Reverting commits
+
+Commits are reverted with `git revert <HASH>`, or `git revert <FROM>..<TO>` for
+multiple commits. Commit metadata and the reason for the revert should be
+appended. Commit message rules about line length and subsystem can be ignored.
+A Pull Request should be raised and approved like any other change.
+
 ### Deprecations
 
 Deprecation refers to the identification of Public APIs that should no longer

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -2,38 +2,30 @@
 
 ## Code of Conduct
 
-The Code of Conduct explains the *bare minimum* behavior
-expectations the Node Foundation requires of its contributors.
-[Please read it before participating.](https://github.com/nodejs/TSC/blob/master/CODE_OF_CONDUCT.md)
+Please read the
+[Code of Conduct](https://github.com/nodejs/TSC/blob/master/CODE_OF_CONDUCT.md)
+which explains the minimum behavior expectations for Node.js contributors.
 
 ## Issue Contributions
 
-When opening new issues or commenting on existing issues on this repository
-please make sure discussions are related to concrete technical issues with the
-Node.js software.
+When opening issues or commenting on existing issues, please make sure
+discussions are related to concrete technical issues with Node.js.
 
-For general help using Node.js, please file an issue at the
+* For general help using Node.js, please file an issue at the
 [Node.js help repository](https://github.com/nodejs/help/issues).
 
-Discussion of non-technical topics including subjects like intellectual
-property, trademark, and high level project questions should move to the
-[Technical Steering Committee (TSC)](https://github.com/nodejs/TSC/issues)
-instead.
+* Discussion of non-technical topics (such as intellectual property and
+trademark) should use the
+[Technical Steering Committee (TSC) repository](https://github.com/nodejs/TSC/issues).
 
 ## Code Contributions
 
-The Node.js project has an open governance model and welcomes new contributors.
-Individuals making significant and valuable contributions are made
-_Collaborators_ and given commit-access to the project. See the
-[GOVERNANCE.md](./GOVERNANCE.md) document for more information about how this
-works.
-
-This document will guide you through the contribution process.
+This section will guide you through the contribution process.
 
 ### Step 1: Fork
 
-Fork the project [on GitHub](https://github.com/nodejs/node) and check out your
-copy locally.
+Fork the project [on GitHub](https://github.com/nodejs/node) and clone your fork
+locally.
 
 ```text
 $ git clone [email protected]:username/node.git
@@ -49,24 +41,18 @@ and built upon.
 #### Dependencies
 
 Node.js has several bundled dependencies in the *deps/* and the *tools/*
-directories that are not part of the project proper. Any changes to files
-in those directories or its subdirectories should be sent to their respective
-projects. Do not send a patch to Node.js. We cannot accept such patches.
+directories that are not part of the project proper. Changes to files in those
+directories should be sent to their respective projects. Do not send a patch to
+Node.js. We cannot accept such patches.
 
 In case of doubt, open an issue in the
 [issue tracker](https://github.com/nodejs/node/issues/) or contact one of the
 [project Collaborators](https://github.com/nodejs/node/#current-project-team-members).
-Especially do so if you plan to work on something big. Nothing is more
-frustrating than seeing your hard work go to waste because your vision
-does not align with the project team. (Node.js has two IRC channels:
+Node.js has two IRC channels:
 [#Node.js](http://webchat.freenode.net/?channels=node.js) for general help and
 questions, and
 [#Node-dev](http://webchat.freenode.net/?channels=node-dev) for development of
-Node.js core specifically).
-
-For instructions on updating the version of V8 included in the *deps/*
-directory, please refer to [the Maintaining V8 in Node.js guide](https://github.com/nodejs/node/blob/master/doc/guides/maintaining-V8.md).
-
+Node.js core specifically.
 
 ### Step 2: Branch
 
@@ -95,35 +81,37 @@ $ git add my/changed/files
 $ git commit
 ```
 
-### Commit guidelines
+### Commit message guidelines
 
-Writing good commit logs is important. A commit log should describe what
-changed and why. Follow these guidelines when writing one:
+The commit message should describe what changed and why.
 
 1. The first line should:
    - contain a short description of the change
    - be 50 characters or less
    - be entirely in lowercase with the exception of proper nouns, acronyms, and
    the words that refer to code, like function/variable names
    - be prefixed with the name of the changed subsystem and start with an
-   imperative verb. Examples: "net: add localAddress and localPort
-   to Socket", "src: fix typos in node_lttng_provider.h"
-   - be meaningful; it is what other people see when they
-   run `git shortlog` or `git log --oneline`.<br>
-   Check the output of `git log --oneline files/you/changed` to find out
-   what subsystem (or subsystems) your changes touch
+   imperative verb. Check the output of `git log --oneline files/you/changed` to
+   find out what subsystems your changes touch.
+
+   Examples:
+   - `net: add localAddress and localPort to Socket`
+   - `src: fix typos in node_lttng_provider.h`
+
+
 2. Keep the second line blank.
 3. Wrap all other lines at 72 columns.
-   - If your patch fixes an open issue, you can add a reference to it at the end
-    of the log. Use the `Fixes:` prefix and the full issue URL. For other references
-    use `Refs:`. For example:
-    ```txt
-    Fixes: https://github.com/nodejs/node/issues/1337
-    Refs: http://eslint.org/docs/rules/space-in-parens.html
-    Refs: https://github.com/nodejs/node/pull/3615
-    ```
 
-A good commit log can look something like this:
+4. If your patch fixes an open issue, you can add a reference to it at the end
+of the log. Use the `Fixes:` prefix and the full issue URL. For other references
+use `Refs:`.
+
+   Examples:
+   - `Fixes: https://github.com/nodejs/node/issues/1337`
+   - `Refs: http://eslint.org/docs/rules/space-in-parens.html`
+   - `Refs: https://github.com/nodejs/node/pull/3615`
+
+Sample complete commit message:
 
 ```txt
 subsystem: explain the commit in one line
@@ -143,7 +131,8 @@ Refs: http://eslint.org/docs/rules/space-in-parens.html
 
 ### Step 4: Rebase
 
-Use `git rebase` (not `git merge`) to sync your work from time to time.
+Use `git rebase` (not `git merge`) to synchronize your work with the main
+repository.
 
 ```text
 $ git fetch upstream
@@ -152,12 +141,12 @@ $ git rebase upstream/master
 
 ### Step 5: Test
 
-Bug fixes and features **should come with tests**. Add your tests in the
-`test/parallel/` directory. For guidance on how to write a test for the Node.js
-project, see this [guide](./doc/guides/writing-tests.md). Looking at other tests
-to see how they should be structured can also help.
+Bug fixes and features should come with tests. Read the
+[guide for writing tests in Node.js](./doc/guides/writing-tests.md). Looking at
+other tests to see how they should be structured can also help. Add your
+tests in the `test/parallel/` directory if you are unsure where to put them.
 
-To run the tests on Unix / macOS:
+To run the tests (including code linting) on Unix / macOS:
 
 ```text
 $ ./configure && make -j4 test
@@ -174,28 +163,31 @@ Windows:
 Make sure the linter does not report any issues and that all tests pass. Please
 do not submit patches that fail either check.
 
-Running `make test`/`vcbuild test` will run the linter as well unless one or
-more tests fail.
-
 If you want to run the linter without running tests, use
 `make lint`/`vcbuild lint`. It will run both JavaScript linting and
 C++ linting.
 
-If you are updating tests and just want to run a single test to check it, you
-can use this syntax to run it exactly as the test harness would:
+If you are updating tests and just want to run a single test to check it:
+
+```text
+$ python tools/test.py -J --mode=release parallel/test-stream2-transform
+```
+
+If you want to check the other options, please refer to the help by using
+the `--help` option
 
 ```text
-$ python tools/test.py -v --mode=release parallel/test-stream2-transform
+$ python tools/test.py --help
 ```
 
-You can run tests directly with node:
+You can usually run tests directly with node:
 
 ```text
 $ ./node ./test/parallel/test-stream2-transform.js
 ```
 
-Remember to recompile with `make -j4` in between test runs if you change
-core modules.
+Remember to recompile with `make -j4` in between test runs if you change code in
+the `lib` or `src` directories.
 
 ### Step 6: Push
 
@@ -208,7 +200,7 @@ Pull requests are usually reviewed within a few days.
 ### Step 7: Discuss and update
 
 You will probably get feedback or requests for changes to your Pull Request.
-This is a big part of the submission process so don't be disheartened!
+This is a big part of the submission process so don't be discouraged!
 
 To make changes to an existing Pull Request, make the changes to your branch.
 When you push that branch to your fork, GitHub will automatically update the

diff --git a/LICENSE b/LICENSE
@@ -100,7 +100,7 @@ The externally maintained libraries used by Node.js are:
   """
     COPYRIGHT AND PERMISSION NOTICE (ICU 58 and later)
 
-    Copyright © 1991-2016 Unicode, Inc. All rights reserved.
+    Copyright © 1991-2017 Unicode, Inc. All rights reserved.
     Distributed under the Terms of Use in http://www.unicode.org/copyright.html
 
     Permission is hereby granted, free of charge, to any person obtaining