chore(mdx): transformed into mdx pages that need to be in mdx

pages/ar/docs/index.md → pages/ar/docs/index.mdx

@@ -19,7 +19,7 @@ labels:
 
 يصف هذا التوثيق الوحدات المضمنة في الـ Node.js، وهو لا يوثق للوحدات المتوفرة عن طريق المجتمع.
 
-<div class="highlight-box">
+<div className="highlight-box">
 
 ### تبحث عن توثيق لنسخة سابقة؟
 

pages/ca/docs/index.md → pages/ca/docs/index.mdx

@@ -21,7 +21,7 @@ relacionats al mateix. També indica quins mètodes són a l'abast per les difer
 
 També descriu els mòduls inclosos que proporciona Node.js, mes no documenta els mòduls que proporciona la comunitat.
 
-<div class="highlight-box">
+<div className="highlight-box">
 
 ### Buscant la referència de l'API per a una versió anterior?
 

pages/de/docs/index.md → pages/de/docs/index.mdx

@@ -24,7 +24,7 @@ Methoden in den verschiedenen Node.js-Versionen verfügbar sind.
 Die API-Referenz beschreibt Module, die in Node.js integriert sind. Module, die
 von der Community zur Verfügung gestellt werden, sind dort nicht dokumentiert.
 
-<div class="highlight-box">
+<div className="highlight-box">
 
 ### Du suchst nach API Referenzen für ältere Versionen?
 

pages/en/blog/npm/peer-dependencies.md → pages/en/blog/npm/peer-dependencies.mdx

@@ -24,22 +24,22 @@ interfering with my package's v2 copy. Everyone's code works!
 
 ## The Problem: Plugins
 
-There's one use case where this falls down, however: *plugins*. A plugin package is meant to be used with another "host"
-package, even though it does not always directly *use* the host package. There are many examples of this pattern in the
+There's one use case where this falls down, however: _plugins_. A plugin package is meant to be used with another "host"
+package, even though it does not always directly _use_ the host package. There are many examples of this pattern in the
 Node.js package ecosystem already:
 
-* Grunt [plugins](http://gruntjs.com/#plugins-all)
-* Chai [plugins](http://chaijs.com/plugins)
-* LevelUP [plugins](https://github.com/rvagg/node-levelup/wiki/Modules)
-* Express [middleware](http://expressjs.com/api.html#middleware)
-* Winston [transports](https://github.com/flatiron/winston/blob/master/docs/transports.md)
+- Grunt [plugins](http://gruntjs.com/#plugins-all)
+- Chai [plugins](http://chaijs.com/plugins)
+- LevelUP [plugins](https://github.com/rvagg/node-levelup/wiki/Modules)
+- Express [middleware](http://expressjs.com/api.html#middleware)
+- Winston [transports](https://github.com/flatiron/winston/blob/master/docs/transports.md)
 
 Even if you're not familiar with any of those use cases, surely you recall "jQuery plugins" from back when you were a
 client-side developer: little `<script>`s you would drop into your page that would attach things to `jQuery.prototype`
 for your later convenience.
 
 In essence, plugins are designed to be used with host packages. But more importantly, they're designed to be used with
-*particular versions* of host packages. For example, versions 1.x and 2.x of my `chai-as-promised` plugin work with
+_particular versions_ of host packages. For example, versions 1.x and 2.x of my `chai-as-promised` plugin work with
 `chai` version 0.5, whereas versions 3.x work with `chai` 1.x. Or, in the faster-paced and less-semver–friendly world of
 Grunt plugins, version 0.3.1 of `grunt-contrib-stylus` works with `grunt` 0.4.0rc4, but breaks when used with `grunt`
 0.4.0rc5 due to removed APIs.
@@ -81,7 +81,7 @@ your imagination.
 
 What we need is a way of expressing these "dependencies" between plugins and their host package. Some way of saying, "I
 only work when plugged in to version 1.2.x of my host package, so if you install me, be sure that it's alongside a
-compatible host." We call this relationship a *peer dependency*.
+compatible host." We call this relationship a _peer dependency_.
 
 The peer dependency idea has been kicked around for [literally](https://github.com/isaacs/npm/issues/930)
 [years](https://github.com/isaacs/npm/issues/1400). After
@@ -122,11 +122,14 @@ peer-depend on, and add it to your `package.json`:
 Now, when installing `chai-as-promised`, the `chai` package will come along with it. And if later you try to install
 another Chai plugin that only works with 0.x versions of Chai, you'll get an error. Nice!
 
-<div class="highlight-box">
-  <strong>UPDATE:</strong> npm versions 1, 2, and 7 will automatically install peerDependencies if they are not explicitly depended upon higher in the dependency tree. For npm versions 3 through 6, you will receive a warning that the peerDependency is not installed instead.
+<div className="highlight-box">
+  <strong>UPDATE:</strong> npm versions 1, 2, and 7 will automatically install
+  peerDependencies if they are not explicitly depended upon higher in the
+  dependency tree. For npm versions 3 through 6, you will receive a warning that
+  the peerDependency is not installed instead.
 </div>
 
-One piece of advice: peer dependency requirements, unlike those for regular dependencies, *should be lenient*. You
+One piece of advice: peer dependency requirements, unlike those for regular dependencies, _should be lenient_. You
 should not lock your peer dependencies down to specific patch versions. It would be really annoying if one Chai plugin
 peer-depended on Chai 1.4.1, while another depended on Chai 1.5.0, simply because the authors were lazy and didn't spend
 the time figuring out the actual minimum version of Chai they are compatible with.

pages/en/docs/guides/buffer-constructor-deprecation.md → pages/en/docs/guides/buffer-constructor-deprecation.mdx

@@ -9,13 +9,15 @@ layout: docs.hbs
 
 This guide explains how to migrate to safe `Buffer` constructor methods. The migration fixes the following deprecation warning:
 
-<div class="highlight-box">
-The Buffer() and new Buffer() constructors are not recommended for use due to security and usability concerns. Please use the new Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() construction methods instead.
+<div className="highlight-box">
+  The Buffer() and new Buffer() constructors are not recommended for use due to
+  security and usability concerns. Please use the new Buffer.alloc(),
+  Buffer.allocUnsafe(), or Buffer.from() construction methods instead.
 </div>
 
-* [Variant 1: Drop support for Node.js ≤ 4.4.x and 5.0.0 — 5.9.x](#variant-1) (*recommended*)
-* [Variant 2: Use a polyfill](#variant-2)
-* [Variant 3: Manual detection, with safeguards](#variant-3)
+- [Variant 1: Drop support for Node.js ≤ 4.4.x and 5.0.0 — 5.9.x](#variant-1) (_recommended_)
+- [Variant 2: Use a polyfill](#variant-2)
+- [Variant 3: Manual detection, with safeguards](#variant-3)
 
 ### Finding problematic bits of code using `grep`
 
@@ -28,9 +30,9 @@ exceptions).
 
 If you’re using Node.js ≥ 8.0.0 (which is recommended), Node.js exposes multiple options that help with finding the relevant pieces of code:
 
-* `--trace-warnings` will make Node.js show a stack trace for this warning and other warnings that are printed by Node.js.
-* `--trace-deprecation` does the same thing, but only for deprecation warnings.
-* `--pending-deprecation` will show more types of deprecation warnings. In particular, it will show the `Buffer()` deprecation warning, even on Node.js 8.
+- `--trace-warnings` will make Node.js show a stack trace for this warning and other warnings that are printed by Node.js.
+- `--trace-deprecation` does the same thing, but only for deprecation warnings.
+- `--pending-deprecation` will show more types of deprecation warnings. In particular, it will show the `Buffer()` deprecation warning, even on Node.js 8.
 
 You can set these flags using environment variables:
 
@@ -63,13 +65,13 @@ described above.
 
 This is the recommended solution nowadays that would imply only minimal overhead.
 
-The Node.js 5.x release line has been unsupported since July 2016, and the Node.js 4.x release line reaches its End of Life in April 2018 (→ [Schedule](https://github.com/nodejs/Release#release-schedule)). This means that these versions of Node.js will *not* receive any updates, even in case of security issues, so using these release lines should be avoided, if at all possible.
+The Node.js 5.x release line has been unsupported since July 2016, and the Node.js 4.x release line reaches its End of Life in April 2018 (→ [Schedule](https://github.com/nodejs/Release#release-schedule)). This means that these versions of Node.js will _not_ receive any updates, even in case of security issues, so using these release lines should be avoided, if at all possible.
 
 What you would do in this case is to convert all `new Buffer()` or `Buffer()` calls to use `Buffer.alloc()` or `Buffer.from()`, in the following way:
 
-* For `new Buffer(number)`, replace it with `Buffer.alloc(number)`.
-* For `new Buffer(string)` (or `new Buffer(string, encoding)`), replace it with `Buffer.from(string)` (or `Buffer.from(string, encoding)`).
-* For all other combinations of arguments (these are much rarer), also replace `new Buffer(...arguments)` with `Buffer.from(...arguments)`.
+- For `new Buffer(number)`, replace it with `Buffer.alloc(number)`.
+- For `new Buffer(string)` (or `new Buffer(string, encoding)`), replace it with `Buffer.from(string)` (or `Buffer.from(string, encoding)`).
+- For all other combinations of arguments (these are much rarer), also replace `new Buffer(...arguments)` with `Buffer.from(...arguments)`.
 
 Note that `Buffer.alloc()` is also _faster_ on the current Node.js versions than
 `new Buffer(size).fill(0)`, which is what you would otherwise need to ensure zero-filling.
@@ -93,7 +95,7 @@ your users will not observe a runtime deprecation warning when running your code
 
 There are three different polyfills available:
 
-* **[safer-buffer](https://www.npmjs.com/package/safer-buffer)** is a drop-in replacement for the
+- **[safer-buffer](https://www.npmjs.com/package/safer-buffer)** is a drop-in replacement for the
   entire `Buffer` API, that will _throw_ when using `new Buffer()`.
 
   You would take exactly the same steps as in [Variant 1](#variant-1), but with a polyfill
@@ -102,7 +104,7 @@ There are three different polyfills available:
   Do not use the old `new Buffer()` API. In any files where the line above is added,
   using old `new Buffer()` API will _throw_.
 
-* **[buffer-from](https://www.npmjs.com/package/buffer-from) and/or
+- **[buffer-from](https://www.npmjs.com/package/buffer-from) and/or
   [buffer-alloc](https://www.npmjs.com/package/buffer-alloc)** are
   [ponyfills](https://ponyfill.com/) for their respective part of the `Buffer` API. You only need
   to add the package(s) corresponding to the API you are using.
@@ -114,7 +116,7 @@ There are three different polyfills available:
   A downside with this approach is slightly more code changes to migrate off them (as you would be
   using e.g. `Buffer.from()` under a different name).
 
-* **[safe-buffer](https://www.npmjs.com/package/safe-buffer)** is also a drop-in replacement for
+- **[safe-buffer](https://www.npmjs.com/package/safe-buffer)** is also a drop-in replacement for
   the entire `Buffer` API, but using `new Buffer()` will still work as before.
 
   A downside to this approach is that it will allow you to also use the older `new Buffer()` API
@@ -205,13 +207,13 @@ const buf = Buffer.alloc ? Buffer.alloc(number) : new Buffer(number).fill(0);
 
 Be extra cautious when using `Buffer.allocUnsafe()`:
 
-* Don't use it if you don't have a good reason to
-  * e.g. you probably won't ever see a performance difference for small buffers, in fact, those
+- Don't use it if you don't have a good reason to
+  - e.g. you probably won't ever see a performance difference for small buffers, in fact, those
     might be even faster with `Buffer.alloc()`,
-  * if your code is not in the hot code path — you also probably won't notice a difference,
-  * keep in mind that zero-filling minimizes the potential risks.
-* If you use it, make sure that you never return the buffer in a partially-filled state,
-  * if you are writing to it sequentially — always truncate it to the actual written length
+  - if your code is not in the hot code path — you also probably won't notice a difference,
+  - keep in mind that zero-filling minimizes the potential risks.
+- If you use it, make sure that you never return the buffer in a partially-filled state,
+  - if you are writing to it sequentially — always truncate it to the actual written length
 
 Errors in handling buffers allocated with `Buffer.allocUnsafe()` could result in various issues,
 ranged from undefined behavior of your code to sensitive data (user input, passwords, certs)
@@ -226,17 +228,17 @@ version (and lacking type checks also adds DoS to the list of potential problems
 
 The `Buffer` constructor could be used to create a buffer in many different ways:
 
-* `new Buffer(42)` creates a `Buffer` of 42 bytes. Before Node.js 8, this buffer contained
-  *arbitrary memory* for performance reasons, which could include anything ranging from
+- `new Buffer(42)` creates a `Buffer` of 42 bytes. Before Node.js 8, this buffer contained
+  _arbitrary memory_ for performance reasons, which could include anything ranging from
   program source code to passwords and encryption keys.
-* `new Buffer('abc')` creates a `Buffer` that contains the UTF-8-encoded version of
+- `new Buffer('abc')` creates a `Buffer` that contains the UTF-8-encoded version of
   the string `'abc'`. A second argument could specify another encoding: for example,
   `new Buffer(string, 'base64')` could be used to convert a Base64 string into the original
   sequence of bytes that it represents.
-* There are several other combinations of arguments.
+- There are several other combinations of arguments.
 
-This meant that in code like `var buffer = new Buffer(foo);`, *it is not possible to tell
-what exactly the contents of the generated buffer are* without knowing the type of `foo`.
+This meant that in code like `var buffer = new Buffer(foo);`, _it is not possible to tell
+what exactly the contents of the generated buffer are_ without knowing the type of `foo`.
 
 Sometimes, the value of `foo` comes from an external source. For example, this function
 could be exposed as a service on a web server, converting a UTF-8 string into its Base64 form:
@@ -250,20 +252,20 @@ function stringToBase64(req, res) {
 }
 ```
 
-Note that this code does *not* validate the type of `req.body.string`:
+Note that this code does _not_ validate the type of `req.body.string`:
 
-* `req.body.string` is expected to be a string. If this is the case, all goes well.
-* `req.body.string` is controlled by the client that sends the request.
-* If `req.body.string` is the *number* `50`, the `rawBytes` would be `50` bytes:
-  * Before Node.js 8, the content would be uninitialized
-  * After Node.js 8, the content would be `50` bytes with the value `0`
+- `req.body.string` is expected to be a string. If this is the case, all goes well.
+- `req.body.string` is controlled by the client that sends the request.
+- If `req.body.string` is the _number_ `50`, the `rawBytes` would be `50` bytes:
+  - Before Node.js 8, the content would be uninitialized
+  - After Node.js 8, the content would be `50` bytes with the value `0`
 
 Because of the missing type check, an attacker could intentionally send a number
 as part of the request. Using this, they can either:
 
-* Read uninitialized memory. This **will** leak passwords, encryption keys and other
+- Read uninitialized memory. This **will** leak passwords, encryption keys and other
   kinds of sensitive information. (Information leak)
-* Force the program to allocate a large amount of memory. For example, when specifying
+- Force the program to allocate a large amount of memory. For example, when specifying
   `500000000` as the input value, each request will allocate 500MB of memory.
   This can be used to either exhaust the memory available of a program completely
   and make it crash, or slow it down significantly. (Denial of Service)
@@ -279,4 +281,4 @@ handled by the program.
 
 Surveys of code in the `npm` ecosystem have shown that the `Buffer()` constructor is still
 widely used. This includes new code, and overall usage of such code has actually been
-*increasing*.
+_increasing_.

pages/en/docs/index.md → pages/en/docs/index.mdx

@@ -19,7 +19,7 @@ The [API reference documentation](https://nodejs.org/api/) provides detailed inf
 
 This documentation describes the built-in modules provided by Node.js. It does not document modules provided by the community.
 
-<div class="highlight-box">
+<div className="highlight-box">
 
 ### Looking for API docs of previous releases?