fastify 5.2.1 → 5.2.2

package/docs/Guides/Testing.md

@@ -340,10 +340,10 @@ test('should ...', {only: true}, t => ...)
 ```
 2. Run `node --test`
 ```bash
-> node --test --test-only --node-arg=--inspect-brk test/<test-file.test.js>
+> node --test --test-only --inspect-brk test/<test-file.test.js>
 ```
 - `--test-only` specifies to run tests with the `only` option enabled
-- `--node-arg=--inspect-brk` will launch the node debugger
+- `--inspect-brk` will launch the node debugger
 3. In VS Code, create and launch a `Node.js: Attach` debug configuration. No
    modification should be necessary.
 

package/docs/Guides/Write-Plugin.md

@@ -14,7 +14,7 @@ suggestion"](https://github.com/fastify/fastify/issues?q=is%3Aissue+is%3Aopen+la
 in our issue tracker!*
 
 ## Code
-Fastify uses different techniques to optimize its code, many of them are
+Fastify uses different techniques to optimize its code, many of which are
 documented in our Guides. We highly recommend you read [the hitchhiker's guide
 to plugins](./Plugins-Guide.md) to discover all the APIs you can use to build
 your plugin and learn how to use them.
@@ -53,8 +53,7 @@ Always put an example file in your repository. Examples are very helpful for
 users and give a very fast way to test your plugin. Your users will be grateful.
 
 ## Test
-It is extremely important that a plugin is thoroughly tested to verify that is
-working properly.
+A plugin **must** be thoroughly tested to verify that is working properly.
 
 A plugin without tests will not be accepted to the ecosystem list. A lack of
 tests does not inspire trust nor guarantee that the code will continue to work

package/docs/Reference/ContentTypeParser.md

@@ -1,38 +1,32 @@
 <h1 align="center">Fastify</h1>
 
 ## `Content-Type` Parser
-Natively, Fastify only supports `'application/json'` and `'text/plain'` content
-types. If the content type is not one of these, an
-`FST_ERR_CTP_INVALID_MEDIA_TYPE` error will be thrown.
-Other common content types are supported through the use of
-[plugins](https://fastify.dev/ecosystem/).
+Fastify natively supports `'application/json'` and `'text/plain'` content types
+with a default charset of `utf-8`. These default parsers can be changed or
+removed.
 
-The default charset is `utf-8`. If you need to support different content types,
-you can use the `addContentTypeParser` API. *The default JSON and/or plain text
-parser can be changed or removed.*
+Unsupported content types will throw an `FST_ERR_CTP_INVALID_MEDIA_TYPE` error.
 
-*Note: If you decide to specify your own content type with the `Content-Type`
-header, UTF-8 will not be the default. Be sure to include UTF-8 like this
-`text/html; charset=utf-8`.*
+To support other content types, use the `addContentTypeParser` API or an
+existing [plugin](https://fastify.dev/ecosystem/).
 
-As with the other APIs, `addContentTypeParser` is encapsulated in the scope in
-which it is declared. This means that if you declare it in the root scope it
-will be available everywhere, while if you declare it inside a plugin it will be
-available only in that scope and its children.
+As with other APIs, `addContentTypeParser` is encapsulated in the scope in which
+it is declared. If declared in the root scope, it is available everywhere; if
+declared in a plugin, it is available only in that scope and its children.
 
 Fastify automatically adds the parsed request payload to the [Fastify
-request](./Request.md) object which you can access with `request.body`.
-
-Note that for `GET` and `HEAD` requests the payload is never parsed. For
-`OPTIONS` and `DELETE` requests the payload is only parsed if the content type
-is given in the content-type header. If it is not given, the
-[catch-all](#catch-all) parser is not executed as with `POST`, `PUT` and
-`PATCH`, but the payload is simply not parsed.
-
-> ## ⚠  Security Notice
-> When using with RegExp to detect `Content-Type`, you should beware of
-> how to properly detect the `Content-Type`. For example, if you need
-> `application/*`, you should use `/^application\/([\w-]+);?/` to match the
+request](./Request.md) object, accessible via `request.body`.
+
+Note that for `GET` and `HEAD` requests, the payload is never parsed. For
+`OPTIONS` and `DELETE` requests, the payload is parsed only if a valid
+`content-type` header is provided. Unlike `POST`, `PUT`, and `PATCH`, the
+[catch-all](#catch-all) parser is not executed, and the payload is simply not
+parsed.
+
+> ⚠ Warning:
+> When using regular expressions to detect `Content-Type`, it is important to
+> ensure proper detection. For example, to match `application/*`, use
+> `/^application\/([\w-]+);?/` to match the
 > [essence MIME type](https://mimesniff.spec.whatwg.org/#mime-type-miscellaneous)
 > only.
 
@@ -70,11 +64,10 @@ fastify.addContentTypeParser('text/json', { parseAs: 'string' }, fastify.getDefa
 ```
 
 Fastify first tries to match a content-type parser with a `string` value before
-trying to find a matching `RegExp`. If you provide overlapping content types,
-Fastify tries to find a matching content type by starting with the last one
-passed and ending with the first one. So if you want to specify a general
-content type more precisely, first specify the general content type and then the
-more specific one, like in the example below.
+trying to find a matching `RegExp`. For overlapping content types, it starts
+with the last one configured and ends with the first (last in, first out).
+To specify a general content type more precisely, first specify the general
+type, then the specific one, as shown below.
 
 ```js
 // Here only the second content type parser is called because its value also matches the first one
@@ -88,10 +81,9 @@ fastify.addContentTypeParser('application/vnd.custom+xml', (request, body, done)
 ```
 
 ### Using addContentTypeParser with fastify.register
-When using `addContentTypeParser` in combination with `fastify.register`,
-`await` should not be used when registering routes. Using `await` causes
-the route registration to be asynchronous and can lead to routes being registered
-before the addContentTypeParser has been set.
+When using `addContentTypeParser` with `fastify.register`, avoid `await`
+when registering routes. Using `await` makes route registration asynchronous,
+potentially registering routes before `addContentTypeParser` is set.
 
 #### Correct Usage
 ```js
@@ -109,14 +101,13 @@ fastify.register((fastify, opts) => {
 });
 ```
 
-Besides the `addContentTypeParser` API there are further APIs that can be used.
-These are `hasContentTypeParser`, `removeContentTypeParser` and
-`removeAllContentTypeParsers`.
+In addition to `addContentTypeParser`, the `hasContentTypeParser`,
+`removeContentTypeParser`, and `removeAllContentTypeParsers` APIs are available.
 
 #### hasContentTypeParser
 
-You can use the `hasContentTypeParser` API to find if a specific content type
-parser already exists.
+Use the `hasContentTypeParser` API to check if a specific content type parser
+exists.
 
 ```js
 if (!fastify.hasContentTypeParser('application/jsoff')){
@@ -130,8 +121,8 @@ if (!fastify.hasContentTypeParser('application/jsoff')){
 
 #### removeContentTypeParser
 
-With `removeContentTypeParser` a single or an array of content types can be
-removed. The method supports `string` and `RegExp` content types.
+`removeContentTypeParser` can remove a single content type or an array of
+content types, supporting both `string` and `RegExp`.
 
 ```js
 fastify.addContentTypeParser('text/xml', function (request, payload, done) {
@@ -145,16 +136,11 @@ fastify.removeContentTypeParser(['application/json', 'text/plain'])
 ```
 
 #### removeAllContentTypeParsers
-
-In the example from just above, it is noticeable that we need to specify each
-content type that we want to remove. To solve this problem Fastify provides the
-`removeAllContentTypeParsers` API. This can be used to remove all currently
-existing content type parsers. In the example below we achieve the same as in
-the example above except that we do not need to specify each content type to
-delete. Just like `removeContentTypeParser`, this API supports encapsulation.
-The API is especially useful if you want to register a [catch-all content type
-parser](#catch-all) that should be executed for every content type and the
-built-in parsers should be ignored as well.
+The `removeAllContentTypeParsers` API removes all existing content type parsers
+eliminating the need to specify each one individually. This API supports
+encapsulation and is useful for registering a
+[catch-all content type parser](#catch-all) that should be executed for every
+content type, ignoring built-in parsers.
 
 ```js
 fastify.removeAllContentTypeParsers()
@@ -166,18 +152,16 @@ fastify.addContentTypeParser('text/xml', function (request, payload, done) {
 })
 ```
 
-**Notice**: The old syntaxes `function(req, done)` and `async function(req)` for
-the parser are still supported but they are deprecated.
+> 🛈 Note: `function(req, done)` and `async function(req)` are
+> still supported but deprecated.
 
 #### Body Parser
-You can parse the body of a request in two ways. The first one is shown above:
-you add a custom content type parser and handle the request stream. In the
-second one, you should pass a `parseAs` option to the `addContentTypeParser`
-API, where you declare how you want to get the body. It could be of type
-`'string'` or `'buffer'`. If you use the `parseAs` option, Fastify will
-internally handle the stream and perform some checks, such as the [maximum
-size](./Server.md#factory-body-limit) of the body and the content length. If the
-limit is exceeded the custom parser will not be invoked.
+The request body can be parsed in two ways. First, add a custom content type
+parser and handle the request stream. Or second, use the `parseAs` option in the
+`addContentTypeParser` API, specifying `'string'` or `'buffer'`. Fastify will
+handle the stream, check the [maximum size](./Server.md#factory-body-limit) of
+the body, and the content length. If the limit is exceeded, the custom parser
+will not be invoked.
 ```js
 fastify.addContentTypeParser('application/json', { parseAs: 'string' }, function (req, body, done) {
   try {
@@ -195,15 +179,14 @@ See
 for an example.
 
 ##### Custom Parser Options
-+ `parseAs` (string): Either `'string'` or `'buffer'` to designate how the
-  incoming data should be collected. Default: `'buffer'`.
++ `parseAs` (string): `'string'` or `'buffer'` to designate how the incoming
+  data should be collected. Default: `'buffer'`.
 + `bodyLimit` (number): The maximum payload size, in bytes, that the custom
   parser will accept. Defaults to the global body limit passed to the [`Fastify
   factory function`](./Server.md#bodylimit).
 
 #### Catch-All
-There are some cases where you need to catch all requests regardless of their
-content type. With Fastify, you can just use the `'*'` content type.
+To catch all requests regardless of content type, use the `'*'` content type:
 ```js
 fastify.addContentTypeParser('*', function (request, payload, done) {
   let data = ''
@@ -213,12 +196,10 @@ fastify.addContentTypeParser('*', function (request, payload, done) {
   })
 })
 ```
+All requests without a corresponding content type parser will be handled by
+this function.
 
-Using this, all requests that do not have a corresponding content type parser
-will be handled by the specified 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) {
@@ -226,7 +207,7 @@ fastify.addContentTypeParser('*', function (request, payload, 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) => {
@@ -254,12 +235,11 @@ fastify.route({
 })
  ```
 
-For piping file uploads you may want to check out [this
-plugin](https://github.com/fastify/fastify-multipart).
+For piping file uploads, check out
+[`@fastify/multipart`](https://github.com/fastify/fastify-multipart).
 
-If you want the content type parser to be executed on all content types and not
-only on those that don't have a specific one, you should call the
-`removeAllContentTypeParsers` method first.
+To execute the content type parser on all content types, call
+`removeAllContentTypeParsers` first.
 
 ```js
 // Without this call, the request body with the content type application/json would be processed by the built-in JSON parser

package/docs/Reference/Decorators.md

@@ -2,16 +2,15 @@
 
 ## Decorators
 
-The decorators API allows customization of the core Fastify objects, such as the
-server instance itself and any request and reply objects used during the HTTP
-request lifecycle. The decorators API can be used to attach any type of property
-to the core objects, e.g. functions, plain objects, or native types.
+The decorators API customizes core Fastify objects, such as the server instance
+and any request and reply objects used during the HTTP request lifecycle. It
+can attach any type of property to core objects, e.g., functions, plain
+objects, or native types.
 
-This API is *synchronous*. Attempting to define a decoration asynchronously
-could result in the Fastify instance booting before the decoration completes its
-initialization. To avoid this issue, and register an asynchronous decoration,
-the `register` API, in combination with `fastify-plugin`, must be used instead.
-To learn more, see the [Plugins](./Plugins.md) documentation.
+This API is *synchronous*. Defining a decoration asynchronously could result in
+the Fastify instance booting before the decoration completes. To register an
+asynchronous decoration, use the `register` API with `fastify-plugin`. See the
+[Plugins](./Plugins.md) documentation for more details.
 
 Decorating core objects with this API allows the underlying JavaScript engine to
 optimize the handling of server, request, and reply objects. This is
@@ -35,9 +34,9 @@ fastify.get('/', function (req, reply) {
 })
 ```
 
-Since the above example mutates the request object after it has already been
-instantiated, the JavaScript engine must deoptimize access to the request
-object. By using the decoration API this deoptimization is avoided:
+The above example mutates the request object after instantiation, causing the
+JavaScript engine to deoptimize access. Using the decoration API avoids this
+deoptimization:
 
 ```js
 // Decorate request with a 'user' property
@@ -54,17 +53,13 @@ fastify.get('/', (req, reply) => {
 })
 ```
 
-Note that it is important to keep the initial shape of a decorated field as
-close as possible to the value intended to be set dynamically in the future.
-Initialize a decorator as a `''` if the intended value is a string, and as
-`null` if it will be an object or a function.
-
-Remember this example works only with value types as reference types will
-thrown and error during the fastify startup. See [decorateRequest](#decorate-request).
-
-See [JavaScript engine fundamentals: Shapes and Inline
-Caches](https://mathiasbynens.be/notes/shapes-ics) for more information on this
-topic.
+Keep the initial shape of a decorated field close to its future dynamic value.
+Initialize a decorator as `''` for strings and `null` for objects or functions.
+This works only with value types; reference types will throw an error during
+Fastify startup. See [decorateRequest](#decorate-request) and
+[JavaScript engine fundamentals: Shapes
+and Inline Caches](https://mathiasbynens.be/notes/shapes-ics)
+for more information.
 
 ### Usage
 <a id="usage"></a>
@@ -72,8 +67,7 @@ topic.
 #### `decorate(name, value, [dependencies])`
 <a id="decorate"></a>
 
-This method is used to customize the Fastify [server](./Server.md)
-instance.
+This method customizes the Fastify [server](./Server.md) instance.
 
 For example, to attach a new method to the server instance:
 
@@ -83,7 +77,7 @@ fastify.decorate('utility', function () {
 })
 ```
 
-As mentioned above, non-function values can be attached to the server instance as:
+Non-function values can also be attached to the server instance:
 
 ```js
 fastify.decorate('conf', {
@@ -118,9 +112,9 @@ fastify.get('/', async function (request, reply) {
 ```
 
 The `dependencies` parameter is an optional list of decorators that the
-decorator being defined relies upon. This list is simply a list of string names
-of other decorators. In the following example, the "utility" decorator depends
-upon "greet" and "hi" decorators:
+decorator being defined relies upon. This list contains the names of other
+decorators. In the following example, the "utility" decorator depends on the
+"greet" and "hi" decorators:
 
 ```js
 async function greetDecorator (fastify, opts) {
@@ -155,18 +149,17 @@ fastify.listen({ port: 3000 }, (err, address) => {
 })
 ```
 
-Note: using an arrow function will break the binding of `this` to the
-`FastifyInstance`.
+Using an arrow function breaks the binding of `this` to
+the `FastifyInstance`.
 
-If a dependency is not satisfied, the `decorate` method will throw an exception.
-The dependency check is performed before the server instance is booted. Thus, it
-cannot occur during runtime.
+If a dependency is not satisfied, the `decorate` method throws an exception.
+The dependency check occurs before the server instance boots, not during
+runtime.
 
 #### `decorateReply(name, value, [dependencies])`
 <a id="decorate-reply"></a>
 
-As the name suggests, this API is used to add new methods/properties to the core
-`Reply` object:
+This API adds new methods/properties to the core `Reply` object:
 
 ```js
 fastify.decorateReply('utility', function () {
@@ -174,29 +167,29 @@ fastify.decorateReply('utility', function () {
 })
 ```
 
-Note: using an arrow function will break the binding of `this` to the Fastify
+Using an arrow function will break the binding of `this` to the Fastify
 `Reply` instance.
 
-Note: using `decorateReply` will throw and error if used with a reference type:
+Using `decorateReply` will throw and error if used with a reference type:
 
 ```js
 // Don't do this
 fastify.decorateReply('foo', { bar: 'fizz'})
 ```
-In this example, the reference of the object would be shared with all the requests
-and **any mutation will impact all requests, potentially creating security
-vulnerabilities or memory leaks**, so Fastify blocks it.
+In this example, the object reference would be shared with all requests, and
+**any mutation will impact all requests, potentially creating security
+vulnerabilities or memory leaks**. Fastify blocks this.
 
 To achieve proper encapsulation across requests configure a new value for each
-incoming request in the [`'onRequest'` hook](./Hooks.md#onrequest). Example:
+incoming request in the [`'onRequest'` hook](./Hooks.md#onrequest).
 
 ```js
 const fp = require('fastify-plugin')
 
 async function myPlugin (app) {
-  app.decorateRequest('foo')
+  app.decorateReply('foo')
   app.addHook('onRequest', async (req, reply) => {
-    req.foo = { bar: 42 }
+    reply.foo = { bar: 42 }
   })
 }
 
@@ -208,8 +201,8 @@ See [`decorate`](#decorate) for information about the `dependencies` parameter.
 #### `decorateRequest(name, value, [dependencies])`
 <a id="decorate-request"></a>
 
-As above with [`decorateReply`](#decorate-reply), this API is used add new
-methods/properties to the core `Request` object:
+As with [`decorateReply`](#decorate-reply), this API adds new methods/properties
+to the core `Request` object:
 
 ```js
 fastify.decorateRequest('utility', function () {
@@ -217,18 +210,18 @@ fastify.decorateRequest('utility', function () {
 })
 ```
 
-Note: using an arrow function will break the binding of `this` to the Fastify
+Using an arrow function will break the binding of `this` to the Fastify
 `Request` instance.
 
-Note: using `decorateRequest` will emit an error if used with a reference type:
+Using `decorateRequest` will emit an error if used with a reference type:
 
 ```js
 // Don't do this
 fastify.decorateRequest('foo', { bar: 'fizz'})
 ```
-In this example, the reference of the object would be shared with all the requests
-and **any mutation will impact all requests, potentially creating security
-vulnerabilities or memory leaks**, so Fastify blocks it.
+In this example, the object reference would be shared with all requests, and
+**any mutation will impact all requests, potentially creating security
+vulnerabilities or memory leaks**. Fastify blocks this.
 
 To achieve proper encapsulation across requests configure a new value for each
 incoming request in the [`'onRequest'` hook](./Hooks.md#onrequest).
@@ -249,7 +242,7 @@ module.exports = fp(myPlugin)
 ```
 
 The hook solution is more flexible and allows for more complex initialization
-because you can add more logic to the `onRequest` hook.
+because more logic can be added to the `onRequest` hook.
 
 Another approach is to use the getter/setter pattern, but it requires 2 decorators:
 
@@ -268,8 +261,7 @@ fastify.get('/', async function (req, reply) {
 })
 ```
 
-This ensures that the `user` property is always unique for each
-request.
+This ensures that the `user` property is always unique for each request.
 
 See [`decorate`](#decorate) for information about the `dependencies` parameter.
 
@@ -305,9 +297,7 @@ fastify.hasReplyDecorator('utility')
 
 Defining a decorator (using `decorate`, `decorateRequest`, or `decorateReply`)
 with the same name more than once in the same **encapsulated** context will
-throw an exception.
-
-As an example, the following will throw:
+throw an exception. For example, the following will throw:
 
 ```js
 const server = require('fastify')()
@@ -358,9 +348,9 @@ server.listen({ port: 3000 })
 ### Getters and Setters
 <a id="getters-setters"></a>
 
-Decorators accept special "getter/setter" objects. These objects have functions
-named `getter` and `setter` (though the `setter` function is optional). This
-allows defining properties via decorators, for example:
+Decorators accept special "getter/setter" objects with `getter` and optional
+`setter` functions. This allows defining properties via decorators,
+for example:
 
 ```js
 fastify.decorate('foo', {

package/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'