v6.13.1 proposal

BUILDING.md

@@ -215,7 +215,8 @@ Prerequisites:
   [Git for Windows](http://git-scm.com/download/win) includes Git Bash
   and tools which can be included in the global `PATH`.
 
-If the path to your build directory contains a space, the build will likely fail.
+If the path to your build directory contains a space or a non-ASCII character, the
+build will likely fail.
 
 ```console
 > .\vcbuild nosign
@@ -385,3 +386,26 @@ and [user guide](https://openssl.org/docs/fips/UserGuide-2.0.pdf).
    `/usr/local/ssl/fips-2.0`
 8. Build Node.js with `make -j`
 9. Verify with `node -p "process.versions.openssl"` (for example `1.0.2a-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.
+
+### Unix / macOS
+
+This command will make `/root/myModule.js` available via
+`require('/root/myModule')` and `./myModule2.js` available via
+`require('myModule2')`.
+
+```console
+$ ./configure --link-module '/root/myModule.js' --link-module './myModule2.js'
+```
+
+### Windows
+
+To make `./myCustomModule.js` available via `require('myCustomModule')`.
+
+```console
+> .\vcbuild link-module './myCustomModule.js'
+```

CHANGELOG.md

@@ -26,7 +26,8 @@ release.
 </tr>
 <tr>
   <td valign="top">
-<b><a href="doc/changelogs/CHANGELOG_V6.md#6.13.0">6.13.0</a></b><br/>
+<b><a href="doc/changelogs/CHANGELOG_V6.md#6.13.1">6.13.1</a></b><br/>
+<a href="doc/changelogs/CHANGELOG_V6.md#6.13.0">6.13.0</a><br/>
 <a href="doc/changelogs/CHANGELOG_V6.md#6.12.3">6.12.3</a><br/>
 <a href="doc/changelogs/CHANGELOG_V6.md#6.12.2">6.12.2</a><br/>
 <a href="doc/changelogs/CHANGELOG_V6.md#6.12.1">6.12.1</a><br/>

COLLABORATOR_GUIDE.md

@@ -127,12 +127,14 @@ Before landing pull requests, sufficient time should be left for input
 from other Collaborators. In general, leave at least 48 hours during the
 week and 72 hours over weekends to account for international time
 differences and work schedules. However, certain types of pull requests
-can be fast-tracked and may be landed after a shorter delay:
-
-* Focused changes that affect only documentation and/or the test suite.
-  `code-and-learn` and `good-first-issue` pull requests typically fall
-  into this category.
-* Changes that fix regressions.
+can be fast-tracked and may be landed after a shorter delay. For example:
+
+* Focused changes that affect only documentation and/or the test suite:
+  * `code-and-learn` tasks typically fall into this category.
+  * `good-first-issue` pull requests may also be suitable.
+* Changes that fix regressions:
+  * Regressions that break the workflow (red CI or broken compilation).
+  * Regressions that happen right before a release, or reported soon after.
 
 When a pull request is deemed suitable to be fast-tracked, label it with
 `fast-track`. The pull request can be landed once 2 or more Collaborators

README.md

@@ -408,8 +408,8 @@ For more information about the governance of the Node.js project, see
 **Kunal Pathak** <kunal.pathak@microsoft.com>
 * [lance](https://github.com/lance) -
 **Lance Ball** <lball@redhat.com>
-* [lucamaraschi](https://github.com/lucamaraschi) -
-**Luca Maraschi** <luca.maraschi@gmail.com> (he/him)
+* [Leko](https://github.com/Leko) -
+**Shingo Inoue** <leko.noor@gmail.com> (he/him)
 * [lpinca](https://github.com/lpinca) -
 **Luigi Pinca** <luigipinca@gmail.com> (he/him)
 * [lucamaraschi](https://github.com/lucamaraschi) -
@@ -500,6 +500,8 @@ For more information about the governance of the Node.js project, see
 **Rich Trott** <rtrott@gmail.com> (he/him)
 * [tunniclm](https://github.com/tunniclm) -
 **Mike Tunnicliffe** <m.j.tunnicliffe@gmail.com>
+* [vdeturckheim](https://github.com/vdeturckheim) -
+**Vladimir de Turckheim** <vlad2t@hotmail.com> (he/him)
 * [vkurchatkin](https://github.com/vkurchatkin) -
 **Vladimir Kurchatkin** <vladimir.kurchatkin@gmail.com>
 * [vsemozhetbyt](https://github.com/vsemozhetbyt) -

doc/api/assert.md

@@ -254,6 +254,8 @@ argument in callbacks.
 ```js
 const assert = require('assert');
 
+assert.ifError(null);
+// OK
 assert.ifError(0);
 // OK
 assert.ifError(1);

doc/api/buffer.md

@@ -1442,7 +1442,7 @@ endian format (`readDoubleBE()` returns big endian, `readDoubleLE()` returns
 little endian).
 
 Setting `noAssert` to `true` allows `offset` to be beyond the end of `buf`, but
-the result should be considered undefined behavior.
+the resulting behavior is undefined.
 
 Examples:
 
@@ -1479,7 +1479,7 @@ endian format (`readFloatBE()` returns big endian, `readFloatLE()` returns
 little endian).
 
 Setting `noAssert` to `true` allows `offset` to be beyond the end of `buf`, but
-the result should be considered undefined behavior.
+the resulting behavior is undefined.
 
 Examples:
 
@@ -1513,7 +1513,7 @@ added: v0.5.0
 Reads a signed 8-bit integer from `buf` at the specified `offset`.
 
 Setting `noAssert` to `true` allows `offset` to be beyond the end of `buf`, but
-the result should be considered undefined behavior.
+the resulting behavior is undefined.
 
 Integers read from a `Buffer` are interpreted as two's complement signed values.
 
@@ -1548,7 +1548,7 @@ the specified endian format (`readInt16BE()` returns big endian,
 `readInt16LE()` returns little endian).
 
 Setting `noAssert` to `true` allows `offset` to be beyond the end of `buf`, but
-the result should be considered undefined behavior.
+the resulting behavior is undefined.
 
 Integers read from a `Buffer` are interpreted as two's complement signed values.
 
@@ -1583,7 +1583,7 @@ the specified endian format (`readInt32BE()` returns big endian,
 `readInt32LE()` returns little endian).
 
 Setting `noAssert` to `true` allows `offset` to be beyond the end of `buf`, but
-the result should be considered undefined behavior.
+the resulting behavior is undefined.
 
 Integers read from a `Buffer` are interpreted as two's complement signed values.
 
@@ -1621,7 +1621,7 @@ and interprets the result as a two's complement signed value. Supports up to 48
 bits of accuracy.
 
 Setting `noAssert` to `true` allows `offset` to be beyond the end of `buf`, but
-the result should be considered undefined behavior.
+the resulting behavior is undefined.
 
 Examples:
 
@@ -1650,7 +1650,7 @@ added: v0.5.0
 Reads an unsigned 8-bit integer from `buf` at the specified `offset`.
 
 Setting `noAssert` to `true` allows `offset` to be beyond the end of `buf`, but
-the result should be considered undefined behavior.
+the resulting behavior is undefined.
 
 Examples:
 
@@ -1683,7 +1683,7 @@ specified endian format (`readUInt16BE()` returns big endian, `readUInt16LE()`
 returns little endian).
 
 Setting `noAssert` to `true` allows `offset` to be beyond the end of `buf`, but
-the result should be considered undefined behavior.
+the resulting behavior is undefined.
 
 Examples:
 
@@ -1722,7 +1722,7 @@ specified endian format (`readUInt32BE()` returns big endian,
 `readUInt32LE()` returns little endian).
 
 Setting `noAssert` to `true` allows `offset` to be beyond the end of `buf`, but
-the result should be considered undefined behavior.
+the resulting behavior is undefined.
 
 Examples:
 
@@ -1758,7 +1758,7 @@ and interprets the result as an unsigned integer. Supports up to 48
 bits of accuracy.
 
 Setting `noAssert` to `true` allows `offset` to be beyond the end of `buf`, but
-the result should be considered undefined behavior.
+the resulting behavior is undefined.
 
 Examples:
 
@@ -2083,7 +2083,7 @@ endian). `value` *should* be a valid 64-bit double. Behavior is undefined when
 `value` is anything other than a 64-bit double.
 
 Setting `noAssert` to `true` allows the encoded form of `value` to extend beyond
-the end of `buf`, but the result should be considered undefined behavior.
+the end of `buf`, but the resulting behavior is undefined.
 
 Examples:
 
@@ -2119,7 +2119,7 @@ endian). `value` *should* be a valid 32-bit float. Behavior is undefined when
 `value` is anything other than a 32-bit float.
 
 Setting `noAssert` to `true` allows the encoded form of `value` to extend beyond
-the end of `buf`, but the result should be considered undefined behavior.
+the end of `buf`, but the resulting behavior is undefined.
 
 Examples:
 
@@ -2153,7 +2153,7 @@ signed 8-bit integer. Behavior is undefined when `value` is anything other than
 a signed 8-bit integer.
 
 Setting `noAssert` to `true` allows the encoded form of `value` to extend beyond
-the end of `buf`, but the result should be considered undefined behavior.
+the end of `buf`, but the resulting behavior is undefined.
 
 `value` is interpreted and written as a two's complement signed integer.
 
@@ -2187,7 +2187,7 @@ endian). `value` *should* be a valid signed 16-bit integer. Behavior is undefine
 when `value` is anything other than a signed 16-bit integer.
 
 Setting `noAssert` to `true` allows the encoded form of `value` to extend beyond
-the end of `buf`, but the result should be considered undefined behavior.
+the end of `buf`, but the resulting behavior is undefined.
 
 `value` is interpreted and written as a two's complement signed integer.
 
@@ -2221,7 +2221,7 @@ endian). `value` *should* be a valid signed 32-bit integer. Behavior is undefine
 when `value` is anything other than a signed 32-bit integer.
 
 Setting `noAssert` to `true` allows the encoded form of `value` to extend beyond
-the end of `buf`, but the result should be considered undefined behavior.
+the end of `buf`, but the resulting behavior is undefined.
 
 `value` is interpreted and written as a two's complement signed integer.
 
@@ -2256,7 +2256,7 @@ Supports up to 48 bits of accuracy. Behavior is undefined when `value` is
 anything other than a signed integer.
 
 Setting `noAssert` to `true` allows the encoded form of `value` to extend beyond
-the end of `buf`, but the result should be considered undefined behavior.
+the end of `buf`, but the resulting behavior is undefined.
 
 Examples:
 
@@ -2290,7 +2290,7 @@ valid unsigned 8-bit integer. Behavior is undefined when `value` is anything
 other than an unsigned 8-bit integer.
 
 Setting `noAssert` to `true` allows the encoded form of `value` to extend beyond
-the end of `buf`, but the result should be considered undefined behavior.
+the end of `buf`, but the resulting behavior is undefined.
 
 Examples:
 
@@ -2324,7 +2324,7 @@ endian). `value` should be a valid unsigned 16-bit integer. Behavior is
 undefined when `value` is anything other than an unsigned 16-bit integer.
 
 Setting `noAssert` to `true` allows the encoded form of `value` to extend beyond
-the end of `buf`, but the result should be considered undefined behavior.
+the end of `buf`, but the resulting behavior is undefined.
 
 Examples:
 
@@ -2362,7 +2362,7 @@ endian). `value` should be a valid unsigned 32-bit integer. Behavior is
 undefined when `value` is anything other than an unsigned 32-bit integer.
 
 Setting `noAssert` to `true` allows the encoded form of `value` to extend beyond
-the end of `buf`, but the result should be considered undefined behavior.
+the end of `buf`, but the resulting behavior is undefined.
 
 Examples:
 
@@ -2400,7 +2400,7 @@ Supports up to 48 bits of accuracy. Behavior is undefined when `value` is
 anything other than an unsigned integer.
 
 Setting `noAssert` to `true` allows the encoded form of `value` to extend beyond
-the end of `buf`, but the result should be considered undefined behavior.
+the end of `buf`, but the resulting behavior is undefined.
 
 Examples:
 

doc/api/child_process.md

@@ -974,10 +974,10 @@ process.send({ foo: 'bar' });
 Child Node.js processes will have a [`process.send()`][] method of their own that
 allows the child to send messages back to the parent.
 
-There is a special case when sending a `{cmd: 'NODE_foo'}` message. All messages
-containing a `NODE_` prefix in its `cmd` property are considered to be reserved
-for use within Node.js core and will not be emitted in the child's
-[`process.on('message')`][] event. Rather, such messages are emitted using the
+There is a special case when sending a `{cmd: 'NODE_foo'}` message. Messages
+containing a `NODE_` prefix in the `cmd` property are reserved for use within
+Node.js core and will not be emitted in the child's [`process.on('message')`][]
+event. Rather, such messages are emitted using the
 `process.on('internalMessage')` event and are consumed internally by Node.js.
 Applications should avoid using such messages or listening for
 `'internalMessage'` events as it is subject to change without notice.

doc/api/crypto.md

@@ -1099,7 +1099,7 @@ password always creates the same key. The low iteration count and
 non-cryptographically secure hash algorithm allow passwords to be tested very
 rapidly.
 
-In line with OpenSSL's recommendation to use pbkdf2 instead of
+In line with OpenSSL's recommendation to use PBKDF2 instead of
 [`EVP_BytesToKey`][] it is recommended that developers derive a key and IV on
 their own using [`crypto.pbkdf2()`][] and to use [`crypto.createCipheriv()`][]
 to create the `Cipher` object. Users should not use ciphers with counter mode
@@ -1154,7 +1154,7 @@ password always creates the same key. The low iteration count and
 non-cryptographically secure hash algorithm allow passwords to be tested very
 rapidly.
 
-In line with OpenSSL's recommendation to use pbkdf2 instead of
+In line with OpenSSL's recommendation to use PBKDF2 instead of
 [`EVP_BytesToKey`][] it is recommended that developers derive a key and IV on
 their own using [`crypto.pbkdf2()`][] and to use [`crypto.createDecipheriv()`][]
 to create the `Decipher` object.

doc/api/http.md

@@ -550,7 +550,7 @@ Once a socket is assigned to this request and is connected
 added: v0.5.9
 -->
 
-* `timeout` {number} Milliseconds before a request is considered to be timed out.
+* `timeout` {number} Milliseconds before a request times out.
 * `callback` {Function} Optional function to be called when a timeout occurs. Same as binding to the `timeout` event.
 
 Once a socket is assigned to this request and is connected

doc/api/process.md

@@ -1300,6 +1300,19 @@ event loop **before** additional I/O is processed.  As a result,
 recursively setting nextTick callbacks will block any I/O from
 happening, just like a `while(true);` loop.
 
+## process.noDeprecation
+<!-- YAML
+added: v0.8.0
+-->
+
+* {boolean}
+
+The `process.noDeprecation` property indicates whether the `--no-deprecation`
+flag is set on the current Node.js process. See the documentation for
+the [`warning` event][process_warning] and the
+[`emitWarning` method][process_emit_warning] for more information about this
+flag's behavior.
+
 ## process.pid
 <!-- YAML
 added: v0.1.15
@@ -1648,6 +1661,19 @@ false
 
 See the [TTY][] documentation for more information.
 
+## process.throwDeprecation
+<!-- YAML
+added: v0.9.12
+-->
+
+* {boolean}
+
+The `process.throwDeprecation` property indicates whether the
+`--throw-deprecation` flag is set on the current Node.js process. See the
+documentation for the [`warning` event][process_warning] and the
+[`emitWarning` method][process_emit_warning] for more information about this
+flag's behavior.
+
 ## process.title
 <!-- YAML
 added: v0.1.104
@@ -1668,6 +1694,19 @@ Node.js v0.8 allowed for longer process title strings by also overwriting the
 `environ` memory but that was potentially insecure and confusing in some
 (rather obscure) cases.
 
+## process.traceDeprecation
+<!-- YAML
+added: v0.8.0
+-->
+
+* {boolean}
+
+The `process.traceDeprecation` property indicates whether the
+`--trace-deprecation` flag is set on the current Node.js process. See the
+documentation for the [`warning` event][process_warning] and the
+[`emitWarning` method][process_emit_warning] for more information about this
+flag's behavior.
+
 ## process.umask([mask])
 <!-- YAML
 added: v0.1.19

doc/api/readline.md

@@ -60,8 +60,8 @@ The `'close'` event is emitted when one of the following occur:
 
 The listener function is called without passing any arguments.
 
-The `readline.Interface` instance should be considered to be "finished" once
-the `'close'` event is emitted.
+The `readline.Interface` instance is finished once the `'close'` event is
+emitted.
 
 ### Event: 'line'
 <!-- YAML