Skip to content

Commit 2fdeb42

Browse files
committed
docs: make note formatting more consistent
1 parent 99f47aa commit 2fdeb42

File tree

4 files changed

+48
-48
lines changed

4 files changed

+48
-48
lines changed

locale/en/docs/guides/backpressuring-in-streams.md

Lines changed: 19 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -81,12 +81,12 @@ To test the results, try opening each compressed file. The file compressed by
8181
the [`zip(1)`][] tool will notify you the file is corrupt, whereas the
8282
compression finished by [`Stream`][] will decompress without error.
8383

84-
Note: In this example, we use `.pipe()` to get the data source from one end
85-
to the other. However, notice there are no proper error handlers attached. If
86-
a chunk of data were to fail to be properly received, the `Readable` source or
87-
`gzip` stream will not be destroyed. [`pump`][] is a utility tool that would
88-
properly destroy all the streams in a pipeline if one of them fails or closes,
89-
and is a must have in this case!
84+
> **Note:** In this example, we use `.pipe()` to get the data source from one end
85+
> to the other. However, notice there are no proper error handlers attached. If
86+
> a chunk of data were to fail to be properly received, the `Readable` source or
87+
> `gzip` stream will not be destroyed. [`pump`][] is a utility tool that would
88+
> properly destroy all the streams in a pipeline if one of them fails or closes,
89+
> and is a must have in this case!
9090
9191
[`pump`][] is only necessary for Node.js 8.x or earlier, as for Node.js 10.x
9292
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.
354354
That's so great! But also not so great when we are trying to understand how to
355355
implement our own custom streams.
356356

357-
Note: In most machines, there is a byte size that determines when a buffer
358-
is full (which will vary across different machines). Node.js allows you to set
359-
your own custom [`highWaterMark`][], but commonly, the default is set to 16kb
360-
(16384, or 16 for objectMode streams). In instances where you might
361-
want to raise that value, go for it, but do so with caution!
357+
> **Note:** In most machines, there is a byte size that determines when a buffer
358+
> is full (which will vary across different machines). Node.js allows you to set
359+
> your own custom [`highWaterMark`][], but commonly, the default is set to 16kb
360+
> (16384, or 16 for objectMode streams). In instances where you might
361+
> want to raise that value, go for it, but do so with caution!
362362
363363
## Lifecycle of `.pipe()`
364364

@@ -410,9 +410,9 @@ stream:
410410
+============+
411411
```
412412

413-
Note: If you are setting up a pipeline to chain together a few streams to
414-
manipulate your data, you will most likely be implementing [`Transform`][]
415-
stream.
413+
> **Note:** If you are setting up a pipeline to chain together a few streams to
414+
> manipulate your data, you will most likely be implementing [`Transform`][]
415+
> stream.
416416
417417
In this case, your output from your [`Readable`][] stream will enter in the
418418
[`Transform`][] and will pipe into the [`Writable`][].
@@ -450,11 +450,11 @@ In general,
450450
3. Streams changes between different Node.js versions, and the library you use.
451451
Be careful and test things.
452452

453-
Note: In regards to point 3, an incredibly useful package for building
454-
browser streams is [`readable-stream`][]. Rodd Vagg has written a
455-
[great blog post][] describing the utility of this library. In short, it
456-
provides a type of automated graceful degradation for [`Readable`][] streams,
457-
and supports older versions of browsers and Node.js.
453+
> **Note:** In regards to point 3, an incredibly useful package for building
454+
> browser streams is [`readable-stream`][]. Rodd Vagg has written a
455+
> [great blog post][] describing the utility of this library. In short, it
456+
> provides a type of automated graceful degradation for [`Readable`][] streams,
457+
> and supports older versions of browsers and Node.js.
458458
459459
## Rules specific to Readable Streams
460460

locale/en/docs/guides/event-loop-timers-and-nexttick.md

Lines changed: 13 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -48,7 +48,7 @@ order of operations.
4848
└───────────────────────────┘
4949
```
5050

51-
*note: each box will be referred to as a "phase" of the event loop.*
51+
> **Note:** Each box will be referred to as a "phase" of the event loop.
5252
5353
Each phase has a FIFO queue of callbacks to execute. While each phase is
5454
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
6565
longer than a timer's threshold. See the [**timers**](#timers) and
6666
[**poll**](#poll) sections for more details.
6767

68-
_**NOTE:** There is a slight discrepancy between the Windows and the
69-
Unix/Linux implementation, but that's not important for this
70-
demonstration. The most important parts are here. There are actually
71-
seven or eight steps, but the ones we care about — ones that Node.js
72-
actually uses - are those above._
68+
> **Note:** There is a slight discrepancy between the Windows and the
69+
> Unix/Linux implementation, but that's not important for this
70+
> demonstration. The most important parts are here. There are actually
71+
> seven or eight steps, but the ones we care about — ones that Node.js
72+
> actually uses - are those above.
7373
7474
## Phases Overview
7575

@@ -99,8 +99,8 @@ scheduled after the specified amount of time has passed; however,
9999
Operating System scheduling or the running of other callbacks may delay
100100
them.
101101

102-
_**Note**: Technically, the [**poll** phase](#poll) controls when timers
103-
are executed._
102+
> **Note:** Technically, the [**poll** phase](#poll) controls when timers
103+
> are executed.
104104
105105
For example, say you schedule a timeout to execute after a 100 ms
106106
threshold, then your script starts asynchronously reading a file which
@@ -145,11 +145,11 @@ the timer's callback. In this example, you will see that the total delay
145145
between the timer being scheduled and its callback being executed will
146146
be 105ms.
147147

148-
Note: To prevent the **poll** phase from starving the event loop, [libuv][]
149-
(the C library that implements the Node.js
150-
event loop and all of the asynchronous behaviors of the platform)
151-
also has a hard maximum (system dependent) before it stops polling for
152-
more events.
148+
> **Note:** To prevent the **poll** phase from starving the event loop,
149+
> [libuv][] (the C library that implements the Node.js
150+
> event loop and all of the asynchronous behaviors of the platform)
151+
> also has a hard maximum (system dependent) before it stops polling for
152+
> more events.
153153
154154
### pending callbacks
155155

locale/en/docs/guides/publishing-napi-modules.md

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -39,15 +39,15 @@ will look like this:
3939
}
4040
```
4141

42-
**Note:** As explained in
43-
["Using dist-tags"][], unlike regular versions, tagged versions cannot be
44-
addressed by version ranges such as `"^2.0.0"` inside `package.json`. The
45-
reason for this is that the tag refers to exactly one version. So, if the
46-
package maintainer chooses to tag a later version of the package using the
47-
same tag, `npm update` will receive the later version. This should be acceptable
48-
given the currently experimental nature of N-API. To depend on an N-API-enabled
49-
version other than the latest published, the `package.json` dependency will
50-
have to refer to the exact version like the following:
42+
> **Note:** As explained in
43+
> ["Using dist-tags"][], unlike regular versions, tagged versions cannot be
44+
> addressed by version ranges such as `"^2.0.0"` inside `package.json`. The
45+
> reason for this is that the tag refers to exactly one version. So, if the
46+
> package maintainer chooses to tag a later version of the package using the
47+
> same tag, `npm update` will receive the later version. This should be acceptable
48+
> given the currently experimental nature of N-API. To depend on an N-API-enabled
49+
> version other than the latest published, the `package.json` dependency will
50+
> have to refer to the exact version like the following:
5151
5252
```json
5353
"dependencies": {

locale/en/docs/guides/timers-in-node.md

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -91,13 +91,13 @@ executing immediate: so immediate
9191
`setImmediate()` returns an `Immediate` object, which can be used to cancel
9292
the scheduled immediate (see `clearImmediate()` below).
9393

94-
Note: Don't get `setImmediate()` confused with `process.nextTick()`. There are
95-
some major ways they differ. The first is that `process.nextTick()` will run
96-
*before* any `Immediate`s that are set as well as before any scheduled I/O.
97-
The second is that `process.nextTick()` is non-clearable, meaning once
98-
code has been scheduled to execute with `process.nextTick()`, the execution
99-
cannot be stopped, just like with a normal function. Refer to [this guide](/en/docs/guides/event-loop-timers-and-nexttick/#process-nexttick)
100-
to better understand the operation of `process.nextTick()`.
94+
> **Note:** Don't get `setImmediate()` confused with `process.nextTick()`. There are
95+
> some major ways they differ. The first is that `process.nextTick()` will run
96+
> *before* any `Immediate`s that are set as well as before any scheduled I/O.
97+
> The second is that `process.nextTick()` is non-clearable, meaning once
98+
> code has been scheduled to execute with `process.nextTick()`, the execution
99+
> cannot be stopped, just like with a normal function. Refer to [this guide](/en/docs/guides/event-loop-timers-and-nexttick/#process-nexttick)
100+
> to better understand the operation of `process.nextTick()`.
101101
102102
### "Infinite Loop" Execution ~ *`setInterval()`*
103103

0 commit comments

Comments
 (0)