docs: make note formatting more consistent (#3520)

GeorgeSapkin · XhmikosR · web-flow · commit 17f641b2915f · 2021-02-14T07:37:51.000+02:00
* docs: make note formatting more consistent

* docs: removed Note word from notes

* docs: fix missed note

Co-authored-by: XhmikosR &lt;xhmikosr@gmail.com&gt;
diff --git a/locale/en/docs/guides/anatomy-of-an-http-transaction.md b/locale/en/docs/guides/anatomy-of-an-http-transaction.md
@@ -57,7 +57,7 @@ relatively painless by putting handy properties onto the `request` object.
 const { method, url } = request;
 ```
 
-> **Note:** The `request` object is an instance of [`IncomingMessage`][].
+> The `request` object is an instance of [`IncomingMessage`][].
 
 The `method` here will always be a normal HTTP method/verb. The `url` is the
 full URL without the server, protocol or port. For a typical URL, this means
@@ -102,7 +102,7 @@ request.on('data', (chunk) => {
 });
 ```
 
-> **Note:** This may seem a tad tedious, and in many cases, it is. Luckily,
+> This may seem a tad tedious, and in many cases, it is. Luckily,
 > there are modules like [`concat-stream`][] and [`body`][] on [`npm`][] which can
 > help hide away some of this logic. It's important to have a good understanding
 > of what's going on before going down that road, and that's why you're here!
@@ -230,7 +230,7 @@ last bit of data on the stream, so we can simplify the example above as follows.
 response.end('<html><body><h1>Hello, World!</h1></body></html>');
 ```
 
-> **Note:** It's important to set the status and headers *before* you start
+> It's important to set the status and headers *before* you start
 > writing chunks of data to the body. This makes sense, since headers come before
 > the body in HTTP responses.
 
@@ -330,7 +330,7 @@ http.createServer((request, response) => {
 }).listen(8080);
 ```
 
-> **Note:** By checking the URL in this way, we're doing a form of "routing".
+> By checking the URL in this way, we're doing a form of "routing".
 > Other forms of routing can be as simple as `switch` statements or as complex as
 > whole frameworks like [`express`][]. If you're looking for something that does
 > routing and nothing else, try [`router`][].
diff --git a/locale/en/docs/guides/backpressuring-in-streams.md b/locale/en/docs/guides/backpressuring-in-streams.md
@@ -81,12 +81,12 @@ To test the results, try opening each compressed file. The file compressed by
 the [`zip(1)`][] tool will notify you the file is corrupt, whereas the
 compression finished by [`Stream`][] will decompress without error.
 
-Note: In this example, we use `.pipe()` to get the data source from one end
-to the other. However, notice there are no proper error handlers attached. If
-a chunk of data were to fail to be properly received, the `Readable` source or
-`gzip` stream will not be destroyed. [`pump`][] is a utility tool that would
-properly destroy all the streams in a pipeline if one of them fails or closes,
-and is a must have in this case!
+> In this example, we use `.pipe()` to get the data source from one end
+> to the other. However, notice there are no proper error handlers attached. If
+> a chunk of data were to fail to be properly received, the `Readable` source or
+> `gzip` stream will not be destroyed. [`pump`][] is a utility tool that would
+> properly destroy all the streams in a pipeline if one of them fails or closes,
+> and is a must have in this case!
 
 [`pump`][] is only necessary for Node.js 8.x or earlier, as for Node.js 10.x
 or later version, [`pipeline`][] is introduced to replace for [`pump`][].
@@ -354,11 +354,11 @@ Well the answer is simple: Node.js does all of this automatically for you.
 That's so great! But also not so great when we are trying to understand how to
 implement our own custom streams.
 
-Note: In most machines, there is a byte size that determines when a buffer
-is full (which will vary across different machines). Node.js allows you to set
-your own custom [`highWaterMark`][], but commonly, the default is set to 16kb
-(16384, or 16 for objectMode streams). In instances where you might
-want to raise that value, go for it, but do so with caution!
+> In most machines, there is a byte size that determines when a buffer
+> is full (which will vary across different machines). Node.js allows you to set
+> your own custom [`highWaterMark`][], but commonly, the default is set to 16kb
+> (16384, or 16 for objectMode streams). In instances where you might
+> want to raise that value, go for it, but do so with caution!
 
 ## Lifecycle of `.pipe()`
 
@@ -410,9 +410,9 @@ stream:
                                        +============+
 ```
 
-Note: If you are setting up a pipeline to chain together a few streams to
-manipulate your data, you will most likely be implementing [`Transform`][]
-stream.
+> If you are setting up a pipeline to chain together a few streams to
+> manipulate your data, you will most likely be implementing [`Transform`][]
+> stream.
 
 In this case, your output from your [`Readable`][] stream will enter in the
 [`Transform`][] and will pipe into the [`Writable`][].
@@ -450,11 +450,11 @@ In general,
 3. Streams changes between different Node.js versions, and the library you use.
 Be careful and test things.
 
-Note: In regards to point 3, an incredibly useful package for building
-browser streams is [`readable-stream`][]. Rodd Vagg has written a
-[great blog post][] describing the utility of this library. In short, it
-provides a type of automated graceful degradation for [`Readable`][] streams,
-and supports older versions of browsers and Node.js.
+> In regards to point 3, an incredibly useful package for building
+> browser streams is [`readable-stream`][]. Rodd Vagg has written a
+> [great blog post][] describing the utility of this library. In short, it
+> provides a type of automated graceful degradation for [`Readable`][] streams,
+> and supports older versions of browsers and Node.js.
 
 ## Rules specific to Readable Streams
 
diff --git a/locale/en/docs/guides/event-loop-timers-and-nexttick.md b/locale/en/docs/guides/event-loop-timers-and-nexttick.md
@@ -48,7 +48,7 @@ order of operations.
    └───────────────────────────┘
 ```
 
-*note: each box will be referred to as a "phase" of the event loop.*
+> Each box will be referred to as a "phase" of the event loop.
 
 Each phase has a FIFO queue of callbacks to execute. While each phase is
 special in its own way, generally, when the event loop enters a given
@@ -65,11 +65,11 @@ result, long running callbacks can allow the poll phase to run much
 longer than a timer's threshold. See the [**timers**](#timers) and
 [**poll**](#poll) sections for more details.
 
-_**NOTE:** There is a slight discrepancy between the Windows and the
-Unix/Linux implementation, but that's not important for this
-demonstration. The most important parts are here. There are actually
-seven or eight steps, but the ones we care about — ones that Node.js
-actually uses - are those above._
+> There is a slight discrepancy between the Windows and the
+> Unix/Linux implementation, but that's not important for this
+> demonstration. The most important parts are here. There are actually
+> seven or eight steps, but the ones we care about — ones that Node.js
+> actually uses - are those above.
 
 ## Phases Overview
 
@@ -99,8 +99,7 @@ scheduled after the specified amount of time has passed; however,
 Operating System scheduling or the running of other callbacks may delay
 them.
 
-_**Note**: Technically, the [**poll** phase](#poll) controls when timers
-are executed._
+> Technically, the [**poll** phase](#poll) controls when timers are executed.
 
 For example, say you schedule a timeout to execute after a 100 ms
 threshold, then your script starts asynchronously reading a file which
@@ -145,11 +144,11 @@ the timer's callback. In this example, you will see that the total delay
 between the timer being scheduled and its callback being executed will
 be 105ms.
 
-Note: To prevent the **poll** phase from starving the event loop, [libuv][]
-(the C library that implements the Node.js
-event loop and all of the asynchronous behaviors of the platform)
-also has a hard maximum (system dependent) before it stops polling for
-more events.
+> To prevent the **poll** phase from starving the event loop, [libuv][]
+> (the C library that implements the Node.js
+> event loop and all of the asynchronous behaviors of the platform)
+> also has a hard maximum (system dependent) before it stops polling for
+> more events.
 
 ### pending callbacks
 
@@ -411,8 +410,8 @@ percentage of the packages on npm. Every day more new modules are being
 added, which means every day we wait, more potential breakages occur.
 While they are confusing, the names themselves won't change.
 
-*We recommend developers use `setImmediate()` in all cases because it's
-easier to reason about.*
+> We recommend developers use `setImmediate()` in all cases because it's
+> easier to reason about.
 
 ## Why use `process.nextTick()`?
 
diff --git a/locale/en/docs/guides/publishing-napi-modules.md b/locale/en/docs/guides/publishing-napi-modules.md
@@ -39,15 +39,15 @@ will look like this:
 }
 ```
 
-**Note:** As explained in
-["Using dist-tags"][], unlike regular versions, tagged versions cannot be
-addressed by version ranges such as `"^2.0.0"` inside `package.json`. The
-reason for this is that the tag refers to exactly one version. So, if the
-package maintainer chooses to tag a later version of the package using the
-same tag, `npm update` will receive the later version. This should be acceptable
-given the currently experimental nature of N-API. To depend on an N-API-enabled
-version other than the latest published, the `package.json` dependency will
-have to refer to the exact version like the following:
+> As explained in
+> ["Using dist-tags"][], unlike regular versions, tagged versions cannot be
+> addressed by version ranges such as `"^2.0.0"` inside `package.json`. The
+> reason for this is that the tag refers to exactly one version. So, if the
+> package maintainer chooses to tag a later version of the package using the
+> same tag, `npm update` will receive the later version. This should be acceptable
+> given the currently experimental nature of N-API. To depend on an N-API-enabled
+> version other than the latest published, the `package.json` dependency will
+> have to refer to the exact version like the following:
 
 ```json
 "dependencies": {
diff --git a/locale/en/docs/guides/timers-in-node.md b/locale/en/docs/guides/timers-in-node.md
@@ -91,13 +91,13 @@ executing immediate: so immediate
 `setImmediate()` returns an `Immediate` object, which can be used to cancel
 the scheduled immediate (see `clearImmediate()` below).
 
-Note: Don't get `setImmediate()` confused with `process.nextTick()`. There are
-some major ways they differ. The first is that `process.nextTick()` will run
-*before* any `Immediate`s that are set as well as before any scheduled I/O.
-The second is that `process.nextTick()` is non-clearable, meaning once
-code has been scheduled to execute with `process.nextTick()`, the execution
-cannot be stopped, just like with a normal function. Refer to [this guide](/en/docs/guides/event-loop-timers-and-nexttick/#process-nexttick)
-to better understand the operation of `process.nextTick()`.
+> Don't get `setImmediate()` confused with `process.nextTick()`. There are
+> some major ways they differ. The first is that `process.nextTick()` will run
+> *before* any `Immediate`s that are set as well as before any scheduled I/O.
+> The second is that `process.nextTick()` is non-clearable, meaning once
+> code has been scheduled to execute with `process.nextTick()`, the execution
+> cannot be stopped, just like with a normal function. Refer to [this guide](/en/docs/guides/event-loop-timers-and-nexttick/#process-nexttick)
+> to better understand the operation of `process.nextTick()`.
 
 ### "Infinite Loop" Execution ~ *`setInterval()`*
 
