docs(reference): even more conciseness (fastify#5951)

* docs(reference): even more conciseness

* docs(reference/principles): add link to lts doc

* chore: shrinky shrink

Author: Fdawgs

docs/Reference/ContentTypeParser.md

@@ -199,16 +199,15 @@ fastify.addContentTypeParser('*', function (request, payload, done) {
 All requests without a corresponding content type parser will be handled by
 this function.
 
-This is also useful for piping the request stream. You can define a content
-parser like:
+This is also useful for piping the request stream. Define a content parser like:
 
 ```js
 fastify.addContentTypeParser('*', function (request, payload, done) {
   done()
 })
 ```
 
-And then access the core HTTP request directly for piping it where you want:
+And then access the core HTTP request directly for piping:
 
 ```js
 app.post('/hello', (request, reply) => {

docs/Reference/Encapsulation.md

@@ -3,21 +3,20 @@
 ## Encapsulation
 <a id="encapsulation"></a>
 
-A fundamental feature of Fastify is the "encapsulation context." The
-encapsulation context governs which [decorators](./Decorators.md), registered
-[hooks](./Hooks.md), and [plugins](./Plugins.md) are available to
-[routes](./Routes.md). A visual representation of the encapsulation context
-is shown in the following figure:
+A fundamental feature of Fastify is the "encapsulation context." It governs
+which [decorators](./Decorators.md), registered [hooks](./Hooks.md), and
+[plugins](./Plugins.md) are available to [routes](./Routes.md). A visual
+representation of the encapsulation context is shown in the following figure:
 
 ![Figure 1](../resources/encapsulation_context.svg)
 
-In the above figure, there are several entities:
+In the figure above, there are several entities:
 
 1. The _root context_
 2. Three _root plugins_
-3. Two _child contexts_ where each _child context_ has
+3. Two _child contexts_, each with:
     * Two _child plugins_
-    * One _grandchild context_ where each _grandchild context_ has
+    * One _grandchild context_, each with:
         - Three _child plugins_
 
 Every _child context_ and _grandchild context_ has access to the _root plugins_.
@@ -26,15 +25,14 @@ _child plugins_ registered within the containing _child context_, but the
 containing _child context_ **does not** have access to the _child plugins_
 registered within its _grandchild context_.
 
-Given that everything in Fastify is a [plugin](./Plugins.md), except for the
+Given that everything in Fastify is a [plugin](./Plugins.md) except for the
 _root context_, every "context" and "plugin" in this example is a plugin
-that can consist of decorators, hooks, plugins, and routes. Thus, to put
-this example into concrete terms, consider a basic scenario of a REST API
-server that has three routes: the first route (`/one`) requires authentication,
-the second route (`/two`) does not, and the third route (`/three`) has
-access to the same context as the second route. Using
-[@fastify/bearer-auth][bearer] to provide the authentication, the code for this
-example is as follows:
+that can consist of decorators, hooks, plugins, and routes. To put this
+example into concrete terms, consider a basic scenario of a REST API server
+with three routes: the first route (`/one`) requires authentication, the
+second route (`/two`) does not, and the third route (`/three`) has access to
+the same context as the second route. Using [@fastify/bearer-auth][bearer] to
+provide authentication, the code for this example is as follows:
 
 ```js
 'use strict'
@@ -52,9 +50,9 @@ fastify.register(async function authenticatedContext (childServer) {
     handler (request, response) {
       response.send({
         answer: request.answer,
-        // request.foo will be undefined as it's only defined in publicContext
+        // request.foo will be undefined as it is only defined in publicContext
         foo: request.foo,
-        // request.bar will be undefined as it's only defined in grandchildContext
+        // request.bar will be undefined as it is only defined in grandchildContext
         bar: request.bar
       })
     }
@@ -71,7 +69,7 @@ fastify.register(async function publicContext (childServer) {
       response.send({
         answer: request.answer,
         foo: request.foo,
-        // request.bar will be undefined as it's only defined in grandchildContext
+        // request.bar will be undefined as it is only defined in grandchildContext
         bar: request.bar
       })
     }
@@ -97,16 +95,16 @@ fastify.register(async function publicContext (childServer) {
 fastify.listen({ port: 8000 })
 ```
 
-The above server example shows all of the encapsulation concepts outlined in the
+The server example above demonstrates the encapsulation concepts from the
 original diagram:
 
 1. Each _child context_ (`authenticatedContext`, `publicContext`, and
-`grandchildContext`) has access to the `answer` request decorator defined in
-the _root context_.
+   `grandchildContext`) has access to the `answer` request decorator defined in
+   the _root context_.
 2. Only the `authenticatedContext` has access to the `@fastify/bearer-auth`
-plugin.
+   plugin.
 3. Both the `publicContext` and `grandchildContext` have access to the `foo`
-request decorator.
+   request decorator.
 4. Only the `grandchildContext` has access to the `bar` request decorator.
 
 To see this, start the server and issue requests:
@@ -125,16 +123,13 @@ To see this, start the server and issue requests:
 ## Sharing Between Contexts
 <a id="shared-context"></a>
 
-Notice that each context in the prior example inherits _only_ from the parent
-contexts. Parent contexts cannot access any entities within their descendent
-contexts. This default is occasionally not desired. In such cases, the
-encapsulation context can be broken through the usage of
-[fastify-plugin][fastify-plugin] such that anything registered in a descendent
-context is available to the containing parent context.
+Each context in the prior example inherits _only_ from its parent contexts. Parent
+contexts cannot access entities within their descendant contexts. If needed,
+encapsulation can be broken using [fastify-plugin][fastify-plugin], making
+anything registered in a descendant context available to the parent context.
 
-Assuming the `publicContext` needs access to the `bar` decorator defined
-within the `grandchildContext` in the previous example, the code can be
-rewritten as:
+To allow `publicContext` access to the `bar` decorator in `grandchildContext`,
+rewrite the code as follows:
 
 ```js
 'use strict'

docs/Reference/HTTP2.md

@@ -2,11 +2,11 @@
 
 ## HTTP2
 
-_Fastify_ supports HTTP2 over either HTTPS (h2) or plaintext (h2c).
+_Fastify_ supports HTTP2 over HTTPS (h2) or plaintext (h2c).
 
 Currently, none of the HTTP2-specific APIs are available through _Fastify_, but
-Node's `req` and `res` can be accessed through our `Request` and `Reply`
-interface. PRs are welcome.
+Node's `req` and `res` can be accessed through the `Request` and `Reply`
+interfaces. PRs are welcome.
 
 ### Secure (HTTPS)
 
@@ -61,16 +61,16 @@ fastify.get('/', function (request, reply) {
 fastify.listen({ port: 3000 })
 ```
 
-You can test your new server with:
+Test the new server with:
 
 ```
 $ npx h2url https://localhost:3000
 ```
 
 ### Plain or insecure
 
-If you are building microservices, you can connect to HTTP2 in plain text,
-however, this is not supported by browsers.
+For microservices, HTTP2 can connect in plain text, but this is not
+supported by browsers.
 
 ```js
 'use strict'
@@ -86,7 +86,7 @@ fastify.get('/', function (request, reply) {
 fastify.listen({ port: 3000 })
 ```
 
-You can test your new server with:
+Test the new server with:
 
 ```
 $ npx h2url http://localhost:3000

docs/Reference/LTS.md

@@ -25,13 +25,11 @@ in this document:
    and verified against alternative runtimes that are compatible with Node.js.
    The maintenance teams of these alternative runtimes are responsible for ensuring
    and guaranteeing these tests work properly.
-      1. [N|Solid](https://docs.nodesource.com/docs/product_suite), maintained by NodeSource,
-      commits to testing and verifying each Fastify major release against the N|Solid
-      LTS versions that are current at the time of the Fastify release.
-      NodeSource guarantees that Fastify will be compatible and function correctly
-      with N|Solid, aligning with the support and compatibility scope of the N|Solid
-      LTS versions available at the time of the Fastify release.
-      This ensures users of N|Solid can confidently use Fastify.
+   1. [N|Solid](https://docs.nodesource.com/docs/product_suite) tests and
+      verifies each Fastify major release against current N|Solid LTS versions.
+      NodeSource ensures Fastify compatibility with N|Solid, aligning with the
+      support scope of N|Solid LTS versions at the time of the Fastify release.
+      This guarantees N|Solid users can confidently use Fastify.
 
 A "month" is defined as 30 consecutive days.
 
@@ -40,13 +38,10 @@ A "month" is defined as 30 consecutive days.
 > As a consequence of providing long-term support for major releases, there are
 > occasions where we need to release breaking changes as a _minor_ version
 > release. Such changes will _always_ be noted in the [release
-> notes](https://github.com/fastify/fastify/releases).
 >
 > To avoid automatically receiving breaking security updates it is possible to
 > use the tilde (`~`) range qualifier. For example, to get patches for the 3.15
 > release, and avoid automatically updating to the 3.16 release, specify the
-> dependency as `"fastify": "~3.15.x"`. This will leave your application
-> vulnerable, so please use with caution.
 
 ### Security Support Beyond LTS
 

docs/Reference/Lifecycle.md

@@ -3,12 +3,11 @@
 ## Lifecycle
 <a id="lifecycle"></a>
 
-Following the schema of the internal lifecycle of Fastify.
+This schema shows the internal lifecycle of Fastify.
 
-On the right branch of every section there is the next phase of the lifecycle,
-on the left branch there is the corresponding error code that will be generated
-if the parent throws an error *(note that all the errors are automatically
-handled by Fastify)*.
+The right branch of each section shows the next phase of the lifecycle. The left
+branch shows the corresponding error code generated if the parent throws an
+error. All errors are automatically handled by Fastify.
 
 ```
 Incoming Request
@@ -42,26 +41,23 @@ Incoming Request
                                                                             └─▶ onResponse Hook
 ```
 
-At any point before or during the `User Handler`, `reply.hijack()` can be called
-to prevent Fastify from:
-- Running all the following hooks and user handler
-- Sending the response automatically
+Before or during the `User Handler`, `reply.hijack()` can be called to:
+- Prevent Fastify from running subsequent hooks and the user handler
+- Prevent Fastify from sending the response automatically
 
-NB (*): If `reply.raw` is used to send a response back to the user, `onResponse`
-hooks will still be executed
+If `reply.raw` is used to send a response, `onResponse` hooks will still
+be executed.
 
 ## Reply Lifecycle
 <a id="reply-lifecycle"></a>
 
-Whenever the user handles the request, the result may be:
+When the user handles the request, the result may be:
 
-- in async handler: it returns a payload
-- in async handler: it throws an `Error`
-- in sync handler: it sends a payload
-- in sync handler: it sends an `Error` instance
+- In an async handler: it returns a payload or throws an `Error`
+- In a sync handler: it sends a payload or an `Error` instance
 
-If the reply was hijacked, we skip all the below steps. Otherwise, when it is
-being submitted, the data flow performed is the following:
+If the reply was hijacked, all subsequent steps are skipped. Otherwise, when
+submitted, the data flow is as follows:
 
 ```
                         ★ schema validation Error
@@ -81,9 +77,8 @@ being submitted, the data flow performed is the following:
                                                                                 └─▶ reply sent
 ```
 
-Note: `reply sent` means that the JSON payload will be serialized by:
-
-- the [reply serialized](./Server.md#setreplyserializer) if set
-- or by the [serializer compiler](./Server.md#setserializercompiler) when a JSON
-  schema has been set for the returning HTTP status code
-- or by the default `JSON.stringify` function
+`reply sent` means the JSON payload will be serialized by one of the following:
+- The [reply serializer](./Server.md#setreplyserializer) if set
+- The [serializer compiler](./Server.md#setserializercompiler) if a JSON schema
+  is set for the HTTP status code
+- The default `JSON.stringify` function

docs/Reference/Middleware.md

@@ -22,36 +22,36 @@ fastify.use(require('ienoopen')())
 fastify.use(require('x-xss-protection')())
 ```
 
-You can also use [`@fastify/middie`](https://github.com/fastify/middie), which provides
-support for simple Express-style middleware but with improved performance:
+[`@fastify/middie`](https://github.com/fastify/middie) can also be used,
+which provides support for simple Express-style middleware with improved
+performance:
 
 ```js
 await fastify.register(require('@fastify/middie'))
 fastify.use(require('cors')())
 ```
 
-Remember that middleware can be encapsulated; this means that you can decide
-where your middleware should run by using `register` as explained in the
-[plugins guide](../Guides/Plugins-Guide.md).
+Middleware can be encapsulated, allowing control over where it runs using
+`register` as explained in the [plugins guide](../Guides/Plugins-Guide.md).
 
-Fastify middleware does not expose the `send` method or other methods specific to
-the Fastify [Reply](./Reply.md#reply) instance. This is because Fastify wraps
+Fastify middleware does not expose the `send` method or other methods specific
+to the Fastify [Reply](./Reply.md#reply) instance. This is because Fastify wraps
 the incoming `req` and `res` Node instances using the
 [Request](./Request.md#request) and [Reply](./Reply.md#reply) objects
-internally, but this is done after the middleware phase. If you need to create
-middleware, you have to use the Node `req` and `res` instances. Otherwise, you
-can use the `preHandler` hook that already has the
-[Request](./Request.md#request) and [Reply](./Reply.md#reply) Fastify instances.
-For more information, see [Hooks](./Hooks.md#hooks).
+internally, but this is done after the middleware phase. To create middleware,
+use the Node `req` and `res` instances. Alternatively, use the `preHandler` hook
+that already has the Fastify [Request](./Request.md#request) and
+[Reply](./Reply.md#reply) instances. For more information, see
+[Hooks](./Hooks.md#hooks).
 
 #### Restrict middleware execution to certain paths
 <a id="restrict-usage"></a>
 
-If you need to only run middleware under certain paths, just pass the path as
-the first parameter to `use` and you are done!
+To run middleware under certain paths, pass the path as the first parameter to
+`use`.
 
-*Note that this does not support routes with parameters, (e.g.
-`/user/:id/comments`) and wildcards are not supported in multiple paths.*
+*Note: This does not support routes with parameters (e.g. `/user/:id/comments`)
+and wildcards are not supported in multiple paths.*
 
 ```js
 const path = require('node:path')
@@ -69,10 +69,10 @@ fastify.use(['/css', '/js'], serveStatic(path.join(__dirname, '/assets')))
 
 ### Alternatives
 
-Fastify offers some alternatives to the most commonly used middleware, such as
-[`@fastify/helmet`](https://github.com/fastify/fastify-helmet) in case of
+Fastify offers alternatives to commonly used middleware, such as
+[`@fastify/helmet`](https://github.com/fastify/fastify-helmet) for
 [`helmet`](https://github.com/helmetjs/helmet),
 [`@fastify/cors`](https://github.com/fastify/fastify-cors) for
 [`cors`](https://github.com/expressjs/cors), and
 [`@fastify/static`](https://github.com/fastify/fastify-static) for
-[`serve-static`](https://github.com/expressjs/serve-static).
+[`serve-static`](https://github.com/expressjs/serve-static).