docs: grammar and sentence structure fixes (#2871)

docs/Benchmarking.md

@@ -1,13 +1,13 @@
 <h1 align="center">Fastify</h1>
 
 ## Benchmarking
-Benchmarking is important if you want to measure how a change can impact the performance of your application. We provide a simple way to benchmark your application from the point of view of a user and contributor. The setup allows you to automate benchmarks in different branches and on different Node.js versions.
+Benchmarking is important if you want to measure how a change can affect the performance of your application. We provide a simple way to benchmark your application from the point of view of a user and contributor. The setup allows you to automate benchmarks in different branches and on different Node.js versions.
 
 The modules we'll use:
 - [Autocannon](https://github.com/mcollina/autocannon): A HTTP/1.1 benchmarking tool written in node.
 - [Branch-comparer](https://github.com/StarpTech/branch-comparer): Checkout multiple git branches, execute scripts and log the results.
 - [Concurrently](https://github.com/kimmobrunfeldt/concurrently): Run commands concurrently.
-- [Npx](https://github.com/zkat/npx) NPM package runner - We are using it to run scripts against different Node.js Versions and to execute local binaries. Shipped with npm@5.2.0.
+- [Npx](https://github.com/npm/npx): NPM package runner used to run scripts against different Node.js Versions and to execute local binaries. Shipped with npm@5.2.0.
 
 ## Simple
 

docs/Decorators.md

@@ -89,7 +89,7 @@ fastify.decorate('conf', {
 })
 ```
 
-To access decorated properties, simply use the name provided to the
+To access decorated properties, use the name provided to the
 decoration API:
 
 ```js

docs/Encapsulation.md

@@ -21,7 +21,7 @@ In the above figure, there are several entities:
         - Three _child plugins_
 
 Every _child context_ and _grandchild context_ has access to the _root plugins_.
-Within each _child context_ the _grandchild contexts_ have access to the
+Within each _child context_, the _grandchild contexts_ have access to the
 _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_.

docs/Getting-Started.md

@@ -118,7 +118,7 @@ module.exports = routes
 In this example, we used the `register` API, which is the core of the Fastify framework. It is the only way to add routes, plugins, et cetera.
 
 At the beginning of this guide, we noted that Fastify provides a foundation that assists with asynchronous bootstrapping of your application. Why is this important?
-Consider the scenario where a database connection is needed to handle data storage. Obviously, the database connection needs to be available before the server is accepting connections. How do we address this problem?<br>
+Consider the scenario where a database connection is needed to handle data storage. The database connection needs to be available before the server is accepting connections. How do we address this problem?<br>
 A typical solution is to use a complex callback, or promises - a system that will mix the framework API with other libraries and the application code.<br>
 Fastify handles this internally, with minimum effort!
 
@@ -285,7 +285,7 @@ fastify.get('/', opts, async (request, reply) => {
   return { hello: 'world' }
 })
 ```
-Simply by specifying a schema as shown, you can speed up serialization by a factor of 2-3. This also helps to protect against leakage of potentially sensitive data, since Fastify will serialize only the data present in the response schema.
+By specifying a schema as shown, you can speed up serialization by a factor of 2-3. This also helps to protect against leakage of potentially sensitive data, since Fastify will serialize only the data present in the response schema.
 Read [Validation and Serialization](Validation-and-Serialization.md) to learn more.
 
 <a name="extend-server"></a>

docs/HTTP2.md

@@ -4,7 +4,7 @@
 
 _Fastify_ offers **experimental support** for HTTP2 starting from 
 Node 8 LTS, which includes HTTP2 without a flag; HTTP2 is supported 
-both over HTTPS or over plaintext.
+over either HTTPS or plaintext.
 
 Currently none of the HTTP2-specific APIs are available through
 _Fastify_, but Node's `req` and `res` can be access through our

docs/LTS.md

@@ -48,4 +48,4 @@ A "month" is to be a period of 30 consecutive days.
 | Windows | Windows Server 2016 R2 | npm                       | 10,12,14  |
 | MacOS   | macOS X Mojave 10.14   | npm                       | 10,12,14  |
 
-Using yarn might require passing the `--ignore-engines` flag.
+Using [yarn](https://yarnpkg.com/) might require passing the `--ignore-engines` flag.

docs/Lifecycle.md

@@ -44,7 +44,7 @@ NB (*): If `reply.raw` is used to send a response back to the user, `onResponse`
 
 ## Reply Lifecycle
 
-Whenever the user handles the request the result may be:
+Whenever the user handles the request, the result may be:
 
 - in async handler: it returns a payload
 - in async handler: it throws an `Error`

docs/Logging.md

@@ -9,7 +9,7 @@ enable it at runtime. We use
 [abstract-logging](https://www.npmjs.com/package/abstract-logging) for
 this purpose.
 
-Since Fastify is focused on performance, it uses [pino](https://github.com/pinojs/pino) as its logger, with the default log level, when enabled, set to `'info'`.
+As Fastify is focused on performance, it uses [pino](https://github.com/pinojs/pino) as its logger, with the default log level, when enabled, set to `'info'`.
 
 Enabling the logger is extremely easy:
 
@@ -116,9 +116,9 @@ app.addHook('preHandler', function (req, reply, done) {
 ```
 
 
-*This option will be ignored by any logger other than Pino.*
+*Any logger other than Pino will ignore this option.*
 
-You can also supply your own logger instance. Instead of passing configuration options, simply pass the instance.
+You can also supply your own logger instance. Instead of passing configuration options, pass the instance.
 The logger you supply must conform to the Pino interface; that is, it must have the following methods:
 `info`, `error`, `debug`, `fatal`, `warn`, `trace`, `child`.
 

docs/Middleware.md

@@ -5,7 +5,7 @@
 Starting with Fastify v3.0.0, middleware is not supported out of the box and requires an external plugin such as [`fastify-express`](https://github.com/fastify/fastify-express) or [`middie`](https://github.com/fastify/middie).
 
 
-An example of registering the [`fastify-express`](https://github.com/fastify/fastify-express) plugin to then `use` Express middleware:
+An example of registering the [`fastify-express`](https://github.com/fastify/fastify-express) plugin to `use` Express middleware:
 
 ```js
 await fastify.register(require('fastify-express'))
@@ -24,9 +24,9 @@ await fastify.register(require('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](Plugins-Guide.md).
+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](Plugins-Guide.md).
 
-Fastify middleware also do 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 which already has the [Request](Request.md#request) and [Reply](Reply.md#reply) Fastify instances. For more information, see [Hooks](Hooks.md#hooks).
+Fastify middleware do 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).
 
 <a name="restrict-usage"></a>
 #### Restrict middleware execution to a certain path(s)

docs/Migration-Guide-V3.md

@@ -79,7 +79,7 @@ const fastify = require('fastify')({
 
 The non-standard `replace-way` shared schema support has been removed. This
 feature has been replace with JSON Schema specification compliant `$ref` based
-substitution. To better understand this change read
+substitution. To help understand this change read
 [Validation and Serialization in Fastify v3](https://dev.to/eomm/validation-and-serialization-in-fastify-v3-2e8l).
 
 **v2:**
@@ -106,7 +106,7 @@ fastify.route({ method, url, schema, handler });
 
 The `setSchemaCompiler` and `setSchemaResolver` options have been replaced
 with the `setValidatorCompiler` to enable future tooling improvements.
-To better understand this change read
+To help understand this change read
 [Validation and Serialization in Fastify v3](https://dev.to/eomm/validation-and-serialization-in-fastify-v3-2e8l).
 
 **v2:**

docs/Plugins-Guide.md

@@ -3,7 +3,7 @@
 # The hitchhiker's guide to plugins
 First of all, `DON'T PANIC`!
 
-Fastify was built from the beginning to be an extremely modular system. We built a powerful API that allows you to add methods and utilities to Fastify by creating a namespace. We built a system that creates an encapsulation model that allows you to split your application in multiple microservices at any moment, without the need to refactor the entire application.
+Fastify was built from the beginning to be an extremely modular system. We built a powerful API that allows you to add methods and utilities to Fastify by creating a namespace. We built a system that creates an encapsulation model, that allows you to split your application in multiple microservices at any moment, without the need to refactor the entire application.
 
 **Table of contents**
 - [Register](#register)
@@ -42,7 +42,7 @@ Where `fastify` is the encapsulated Fastify instance, `options` is the options o
 
 Fastify's plugin model is fully reentrant and graph-based, it handles asynchronous code without any problems and it enforces both the load and close order of plugins. *How?* Glad you asked, check out [`avvio`](https://github.com/mcollina/avvio)! Fastify starts loading the plugin __after__ `.listen()`, `.inject()` or `.ready()` are called.
 
-Inside a plugin you can do whatever you want, register routes, utilities (we'll see this in a moment) and do nested registers, just remember to call `done` when everything is set up!
+Inside a plugin you can do whatever you want, register routes, utilities (we will see this in a moment) and do nested registers, just remember to call `done` when everything is set up!
 ```js
 module.exports = function (fastify, options, done) {
   fastify.get('/plugin', (request, reply) => {
@@ -68,7 +68,7 @@ module.exports = function (a, b) {
 const util = require('./your-awesome-utility')
 console.log(util('that is ', 'awesome'))
 ```
-And now you will import your utility in every file you need it in. (And don't forget that you will probably also need it in your tests).
+Now you will import your utility in every file you need it in. (And do not forget that you will probably also need it in your tests).
 
 Fastify offers you a more elegant and comfortable way to do this, *decorators*.
 Creating a decorator is extremely easy, just use the [`decorate`](Decorators.md) API:
@@ -114,7 +114,7 @@ fastify.register((instance, opts, done) => {
   done()
 })
 ```
-*Take home message: if you need an utility which is available in every part of your application, take care that it's declared in the root scope of your application. If that's not an option you can use the `fastify-plugin` utility as described [here](#distribution).*
+*Take home message: if you need a utility which is available in every part of your application, take care that it's declared in the root scope of your application. If that is not an option you can use the `fastify-plugin` utility as described [here](#distribution).*
 
 `decorate` is not the only API that you can use to extend the server functionality, you can also use `decorateRequest` and `decorateReply`.
 
@@ -131,7 +131,7 @@ fastify.get('/html', (request, reply) => {
     .send(fastify.html({ hello: 'world' }))
 })
 ```
-It works, but it could be way better!
+It works, but it could be much better!
 ```js
 fastify.decorateReply('html', function (payload) {
   this.type('text/html') // This is the 'Reply' object
@@ -143,7 +143,7 @@ fastify.get('/html', (request, reply) => {
 })
 ```
 
-And in the same way you can do this for the `request` object:
+In the same way you can do this for the `request` object:
 ```js
 fastify.decorate('getHeader', (req, header) => {
   return req.headers[header]
@@ -158,7 +158,7 @@ fastify.get('/happiness', (request, reply) => {
   reply.send({ happy: request.isHappy })
 })
 ```
-Again, it works, but it can be way better!
+Again, it works, but it can be much better!
 ```js
 fastify.decorateRequest('setHeader', function (header) {
   this.isHappy = this.headers[header]
@@ -176,7 +176,7 @@ fastify.get('/happiness', (request, reply) => {
 })
 ```
 
-We've seen how to extend server functionality and how to handle the encapsulation system, but what if you need to add a function that must be executed every time when the server "[emits](Lifecycle.md)" an event?
+We have seen how to extend server functionality and how to handle the encapsulation system, but what if you need to add a function that must be executed every time when the server "[emits](Lifecycle.md)" an event?
 
 <a name="hooks"></a>
 ## Hooks
@@ -213,7 +213,7 @@ fastify.get('/plugin2', (request, reply) => {
   reply.send(request)
 })
 ```
-Now for every request, you will run your utility. Obviously you can register as many hooks as you need.<br>
+Now for every request, you will run your utility. You can register as many hooks as you need.<br>
 Sometimes you want a hook that should be executed for just a subset of routes, how can you do that? Yep, encapsulation!
 
 ```js
@@ -242,9 +242,9 @@ As you probably noticed by now, `request` and `reply` are not the standard Nodej
 
 <a name="distribution"></a>
 ## How to handle encapsulation and distribution
-Perfect, now you know (almost) all of the tools that you can use to extend Fastify. But chances are that you came across one big issue: how is distribution handled?
+Perfect, now you know (almost) all of the tools that you can use to extend Fastify. Nevertheless, chances are that you came across one big issue: how is distribution handled?
 
-The preferred way to distribute a utility is to wrap all your code inside a `register`, in this way your plugin can support asynchronous bootstrapping *(since `decorate` is a synchronous API)*, in the case of a database connection for example.
+The preferred way to distribute a utility is to wrap all your code inside a `register`. Using this, your plugin can support asynchronous bootstrapping *(since `decorate` is a synchronous API)*, in the case of a database connection for example.
 
 *Wait, what? Didn't you tell me that `register` creates an encapsulation and that the stuff I create inside will not be available outside?*<br>
 Yes, I said that. But what I didn't tell you, is that you can tell to Fastify to avoid this behaviour, with the [`fastify-plugin`](https://github.com/fastify/fastify-plugin) module.
@@ -263,7 +263,7 @@ module.exports = fp(dbPlugin)
 ```
 You can also tell `fastify-plugin` to check the installed version of Fastify, in case you need a specific API.
 
-As we mentioned earlier, Fastify starts loading its plugins __after__ `.listen()`, `.inject()` or `.ready()` are called and as such, __after__ they have been declared. This means that, even though the plugin may inject variables to the external fastify instance via [`decorate`](Decorators.md), the decorated variables will not be accessible before calling `.listen()`, `.inject()` or `.ready()`.
+As we mentioned earlier, Fastify starts loading its plugins __after__ `.listen()`, `.inject()` or `.ready()` are called and as such, __after__ they have been declared. This means that, even though the plugin may inject variables to the external Fastify instance via [`decorate`](Decorators.md), the decorated variables will not be accessible before calling `.listen()`, `.inject()` or `.ready()`.
 
 In case you rely on a variable injected by a preceding plugin and want to pass that in the `options` argument of `register`, you can do so by using a function instead of an object:
 ```js
@@ -283,7 +283,7 @@ fastify.register(require('your-plugin'), parent => {
   return { connection: parent.db, otherOption: 'foo-bar' }
 })
 ```
-In the above example, the `parent` variable of the function passed in as the second argument of `register` is a copy of the **external fastify instance** that the plugin was registered at. This means that we are able to access any variables that were injected by preceding plugins in the order of declaration.
+In the above example, the `parent` variable of the function passed in as the second argument of `register` is a copy of the **external Fastify instance** that the plugin was registered at. This means that we are able to access any variables that were injected by preceding plugins in the order of declaration.
 
 <a name="esm-support"></a>
 ## ESM support
@@ -300,7 +300,7 @@ async function plugin (fastify, opts) {
 
 export default plugin
 ```
-__Note__: Fastify doesn't support named imports within an ESM context. Instead, the `default` export is available. 
+__Note__: Fastify does not support named imports within an ESM context. Instead, the `default` export is available. 
 
 ```js
 // server.mjs
@@ -326,7 +326,7 @@ The callback changes based on the parameters you are giving:
 
 1. If no parameter is given to the callback and there is an error, that error will be passed to the next error handler.
 1. If one parameter is given to the callback, that parameter will be the error object.
-1. If two parameters are given to the callback, the first will be the error object, the second will be the done callback.
+1. If two parameters are given to the callback, the first will be the error object; the second will be the done callback.
 1. If three parameters are given to the callback, the first will be the error object, the second will be the top-level context unless you have specified both server and override, in that case, the context will be what the override returns, and the third the done callback.
 
 Let's see how to use it: