fastify 5.0.0 → 5.2.0

package/docs/Guides/Prototype-Poisoning.md

@@ -8,7 +8,7 @@
 <a id="pp"></a>
 
 Based on the article by Eran Hammer,the issue is created by a web security bug.
-It is also a perfect illustration of the efforts required to maintain 
+It is also a perfect illustration of the efforts required to maintain
 open-source software and the limitations of existing communication channels.
 
 But first, if we use a JavaScript framework to process incoming JSON data, take
@@ -16,7 +16,7 @@ a moment to read up on [Prototype Poisoning](https://medium.com/intrinsic/javasc
 in general, and the specific
 [technical details](https://github.com/hapijs/hapi/issues/3916) of this issue.
 This could be a critical issue so, we might need to verify your own code first.
-It focuses on specific framework however, any solution that uses `JSON.parse()` 
+It focuses on specific framework however, any solution that uses `JSON.parse()`
 to process external data is potentially at risk.
 
 ### BOOM
@@ -42,7 +42,7 @@ defect a validation library can have.
 
 To understand this, we need to understand how JavaScript works a bit.
 Every object in JavaScript can have a prototype. It is a set of methods and
-properties it "inherits" from another object. I have put inherits in quotes 
+properties it "inherits" from another object. I have put inherits in quotes
 because JavaScript isn't really an object-oriented language. It is a prototype-
 based object-oriented language.
 

package/docs/Guides/Recommendations.md

@@ -307,22 +307,22 @@ readinessProbe:
 ## Capacity Planning For Production
 <a id="capacity"></a>
 
-In order to rightsize the production environment for your Fastify application, 
-it is highly recommended that you perform your own measurements against 
+In order to rightsize the production environment for your Fastify application,
+it is highly recommended that you perform your own measurements against
 different configurations of the environment, which may
 use real CPU cores, virtual CPU cores (vCPU), or even fractional
 vCPU cores. We will use the term vCPU throughout this
 recommendation to represent any CPU type.
 
-Tools such as [k6](https://github.com/grafana/k6) 
+Tools such as [k6](https://github.com/grafana/k6)
 or [autocannon](https://github.com/mcollina/autocannon) can be used for
 conducting the necessary performance tests.
 
 That said, you may also consider the following as a rule of thumb:
 
-* To have the lowest possible latency, 2 vCPU are recommended per app 
-instance (e.g., a k8s pod). The second vCPU will mostly be used by the 
-garbage collector (GC) and libuv threadpool. This will minimize the latency 
+* To have the lowest possible latency, 2 vCPU are recommended per app
+instance (e.g., a k8s pod). The second vCPU will mostly be used by the
+garbage collector (GC) and libuv threadpool. This will minimize the latency
 for your users, as well as the memory usage, as the GC will be run more
 frequently. Also, the main thread won't have to stop to let the GC run.
 
@@ -330,7 +330,7 @@ frequently. Also, the main thread won't have to stop to let the GC run.
 requests per second per vCPU available), consider using a smaller amount of vCPUs
 per app instance. It is totally fine to run Node.js applications with 1 vCPU.
 
-* You may experiment with an even smaller amount of vCPU, which may provide 
+* You may experiment with an even smaller amount of vCPU, which may provide
 even better throughput in certain use-cases. There are reports of API gateway
 solutions working well with 100m-200m vCPU in Kubernetes.
 
@@ -347,7 +347,7 @@ would be exposing metrics endpoints on a separate port,
 to prevent public access, when using a reverse proxy or an ingress
 firewall is not an option.
 
-It is perfectly fine to spin up several Fastify instances within the same 
-Node.js process and run them concurrently, even in high load systems. 
+It is perfectly fine to spin up several Fastify instances within the same
+Node.js process and run them concurrently, even in high load systems.
 Each Fastify instance only generates as much load as the traffic it receives,
 plus the memory used for that Fastify instance.

package/docs/Guides/Serverless.md

@@ -36,10 +36,10 @@ snippet of code.
 
 To integrate with AWS, you have two choices of library:
 
-- Using [@fastify/aws-lambda](https://github.com/fastify/aws-lambda-fastify) 
+- Using [@fastify/aws-lambda](https://github.com/fastify/aws-lambda-fastify)
   which only adds API Gateway support but has heavy optimizations for fastify.
-- Using [@h4ad/serverless-adapter](https://github.com/H4ad/serverless-adapter) 
-  which is a little slower as it creates an HTTP request for each AWS event but 
+- Using [@h4ad/serverless-adapter](https://github.com/H4ad/serverless-adapter)
+  which is a little slower as it creates an HTTP request for each AWS event but
   has support for more AWS services such as: AWS SQS, AWS SNS and others.
 
 So you can decide which option is best for you, but you can test both libraries.
@@ -263,7 +263,7 @@ curl -X POST https://$GOOGLE_REGION-$GOOGLE_PROJECT.cloudfunctions.net/me \
 
 ## Google Firebase Functions
 
-Follow this guide if you want to use Fastify as the HTTP framework for 
+Follow this guide if you want to use Fastify as the HTTP framework for
 Firebase Functions instead of the vanilla JavaScript router provided with
 `onRequest(async (req, res) => {}`.
 
@@ -280,7 +280,7 @@ const { onRequest } = require("firebase-functions/v2/https")
 ### Creation of Fastify instance
 
 Create the Fastify instance and encapsulate the returned application instance
-in a function which will register routes, await the server's processing of 
+in a function which will register routes, await the server's processing of
 plugins, hooks and other settings. As follows:
 
 ```js

package/docs/Guides/Testing.md

@@ -5,15 +5,15 @@
 
 Testing is one of the most important parts of developing an application. Fastify
 is very flexible when it comes to testing and is compatible with most testing
-frameworks (such as [Tap](https://www.npmjs.com/package/tap), which is used in
-the examples below).
+frameworks (such as [Node Test Runner](https://nodejs.org/api/test.html),
+which is used in the examples below).
 
 ## Application
 
 Let's `cd` into a fresh directory called 'testing-example' and type `npm init
 -y` in our terminal.
 
-Run `npm i fastify && npm i tap pino-pretty -D`
+Run `npm i fastify && npm i pino-pretty -D`
 
 ### Separating concerns makes testing easy
 
@@ -113,24 +113,25 @@ Now we can replace our `console.log` calls with actual tests!
 
 In your `package.json` change the "test" script to:
 
-`"test": "tap --reporter=list --watch"`
+`"test": "node --test --watch"`
 
 **app.test.js**:
 
 ```js
 'use strict'
 
-const { test } = require('tap')
+const { test } = require('node:test')
 const build = require('./app')
 
 test('requests the "/" route', async t => {
+  t.plan(1)
   const app = build()
 
   const response = await app.inject({
     method: 'GET',
     url: '/'
   })
-  t.equal(response.statusCode, 200, 'returns a status code of 200')
+  t.assert.strictEqual(response.statusCode, 200, 'returns a status code of 200')
 })
 ```
 
@@ -214,26 +215,26 @@ module.exports = buildFastify
 
 **test.js**
 ```js
-const tap = require('tap')
+const { test } = require('node:test')
 const buildFastify = require('./app')
 
-tap.test('GET `/` route', t => {
+test('GET `/` route', t => {
   t.plan(4)
 
   const fastify = buildFastify()
 
   // At the end of your tests it is highly recommended to call `.close()`
   // to ensure that all connections to external services get closed.
-  t.teardown(() => fastify.close())
+  t.after(() => fastify.close())
 
   fastify.inject({
     method: 'GET',
     url: '/'
   }, (err, response) => {
-    t.error(err)
-    t.equal(response.statusCode, 200)
-    t.equal(response.headers['content-type'], 'application/json; charset=utf-8')
-    t.same(response.json(), { hello: 'world' })
+    t.assert.ifError(err)
+    t.assert.strictEqual(response.statusCode, 200)
+    t.assert.strictEqual(response.headers['content-type'], 'application/json; charset=utf-8')
+    t.assert.deepStrictEqual(response.json(), { hello: 'world' })
   })
 })
 ```
@@ -248,11 +249,11 @@ Uses **app.js** from the previous example.
 
 **test-listen.js** (testing with [`undici`](https://www.npmjs.com/package/undici))
 ```js
-const tap = require('tap')
+const { test } = require('node:test')
 const { Client } = require('undici')
 const buildFastify = require('./app')
 
-tap.test('should work with undici', async t => {
+test('should work with undici', async t => {
   t.plan(2)
 
   const fastify = buildFastify()
@@ -263,63 +264,64 @@ tap.test('should work with undici', async t => {
     'http://localhost:' + fastify.server.address().port, {
       keepAliveTimeout: 10,
       keepAliveMaxTimeout: 10
-    } 
+    }
   )
 
-  t.teardown(() => {
+  t.after(() => {
     fastify.close()
     client.close()
   })
 
   const response = await client.request({ method: 'GET', path: '/' })
 
-  t.equal(await response.body.text(), '{"hello":"world"}')
-  t.equal(response.statusCode, 200)
+  t.assert.strictEqual(await response.body.text(), '{"hello":"world"}')
+  t.assert.strictEqual(response.statusCode, 200)
 })
 ```
 
-Alternatively, starting with Node.js 18, 
-[`fetch`](https://nodejs.org/docs/latest-v18.x/api/globals.html#fetch) 
+Alternatively, starting with Node.js 18,
+[`fetch`](https://nodejs.org/docs/latest-v18.x/api/globals.html#fetch)
 may be used without requiring any extra dependencies:
 
 **test-listen.js**
 ```js
-const tap = require('tap')
+const { test } = require('node:test')
 const buildFastify = require('./app')
 
-tap.test('should work with fetch', async t => {
+test('should work with fetch', async t => {
   t.plan(3)
 
   const fastify = buildFastify()
 
-  t.teardown(() => fastify.close())
+  t.after(() => fastify.close())
 
   await fastify.listen()
-  
+
   const response = await fetch(
     'http://localhost:' + fastify.server.address().port
   )
 
-  t.equal(response.status, 200)
-  t.equal(
+  t.assert.strictEqual(response.status, 200)
+  t.assert.strictEqual(
     response.headers.get('content-type'),
     'application/json; charset=utf-8'
   )
-  t.has(await response.json(), { hello: 'world' })
+  const jsonResult = await response.json()
+  t.assert.strictEqual(jsonResult.hello, 'world')
 })
 ```
 
 **test-ready.js** (testing with
 [`SuperTest`](https://www.npmjs.com/package/supertest))
 ```js
-const tap = require('tap')
+const { test } = require('node:test')
 const supertest = require('supertest')
 const buildFastify = require('./app')
 
-tap.test('GET `/` route', async (t) => {
+test('GET `/` route', async (t) => {
   const fastify = buildFastify()
 
-  t.teardown(() => fastify.close())
+  t.after(() => fastify.close())
 
   await fastify.ready()
 
@@ -327,21 +329,20 @@ tap.test('GET `/` route', async (t) => {
     .get('/')
     .expect(200)
     .expect('Content-Type', 'application/json; charset=utf-8')
-  t.same(response.body, { hello: 'world' })
+  t.assert.deepStrictEqual(response.body, { hello: 'world' })
 })
 ```
 
-### How to inspect tap tests
+### How to inspect node tests
 1. Isolate your test by passing the `{only: true}` option
 ```javascript
 test('should ...', {only: true}, t => ...)
 ```
-2. Run `tap` using `npx`
+2. Run `node --test`
 ```bash
-> npx tap -O -T --node-arg=--inspect-brk test/<test-file.test.js>
+> node --test --test-only --node-arg=--inspect-brk test/<test-file.test.js>
 ```
-- `-O` specifies to run tests with the `only` option enabled
-- `-T` specifies not to timeout (while you're debugging)
+- `--test-only` specifies to run tests with the `only` option enabled
 - `--node-arg=--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.
@@ -355,7 +356,7 @@ Now you should be able to step through your test file (and the rest of
 Let's `cd` into a fresh directory called 'testing-plugin-example' and type `npm init
 -y` in our terminal.
 
-Run `npm i fastify fastify-plugin && npm i tap -D`
+Run `npm i fastify fastify-plugin`
 
 **plugin/myFirstPlugin.js**:
 
@@ -376,16 +377,16 @@ A basic example of a Plugin. See [Plugin Guide](./Plugins-Guide.md)
 
 ```js
 const Fastify = require("fastify");
-const tap = require("tap");
+const { test } = require("node:test");
 const myPlugin = require("../plugin/myFirstPlugin");
 
-tap.test("Test the Plugin Route", async t => {
+test("Test the Plugin Route", async t => {
     // Create a mock fastify application to test the plugin
     const fastify = Fastify()
 
     fastify.register(myPlugin)
 
-    // Add an endpoint of your choice 
+    // Add an endpoint of your choice
     fastify.get("/", async (request, reply) => {
         return ({ message: request.helloRequest })
     })
@@ -395,7 +396,7 @@ tap.test("Test the Plugin Route", async t => {
         method: "GET",
         url: "/"
     })
-    
+
   console.log('status code: ', fastifyResponse.statusCode)
   console.log('body: ', fastifyResponse.body)
 })
@@ -412,18 +413,18 @@ Now we can replace our `console.log` calls with actual tests!
 
 In your `package.json` change the "test" script to:
 
-`"test": "tap --reporter=list --watch"`
+`"test": "node --test --watch"`
 
-Create the tap test for the endpoint.
+Create the test for the endpoint.
 
 **test/myFirstPlugin.test.js**:
 
 ```js
 const Fastify = require("fastify");
-const tap = require("tap");
+const { test } = require("node:test");
 const myPlugin = require("../plugin/myFirstPlugin");
 
-tap.test("Test the Plugin Route", async t => {
+test("Test the Plugin Route", async t => {
     // Specifies the number of test
     t.plan(2)
 
@@ -439,9 +440,9 @@ tap.test("Test the Plugin Route", async t => {
         method: "GET",
         url: "/"
     })
-    
-    t.equal(fastifyResponse.statusCode, 200)
-    t.same(JSON.parse(fastifyResponse.body), { message: "Hello World" })
+
+    t.assert.strictEqual(fastifyResponse.statusCode, 200)
+    t.assert.deepStrictEqual(JSON.parse(fastifyResponse.body), { message: "Hello World" })
 })
 ```
 
@@ -453,10 +454,10 @@ Test the ```.decorate()``` and ```.decorateRequest()```.
 
 ```js
 const Fastify = require("fastify");
-const tap = require("tap");
+const { test }= require("node:test");
 const myPlugin = require("../plugin/myFirstPlugin");
 
-tap.test("Test the Plugin Route", async t => {
+test("Test the Plugin Route", async t => {
     t.plan(5)
     const fastify = Fastify()
 
@@ -464,9 +465,9 @@ tap.test("Test the Plugin Route", async t => {
 
     fastify.get("/", async (request, reply) => {
         // Testing the fastify decorators
-        t.not(request.helloRequest, null) 
-        t.ok(request.helloRequest, "Hello World")
-        t.ok(fastify.helloInstance, "Hello Fastify Instance")
+        t.assert.ifError(request.helloRequest)
+        t.assert.ok(request.helloRequest, "Hello World")
+        t.assert.ok(fastify.helloInstance, "Hello Fastify Instance")
         return ({ message: request.helloRequest })
     })
 
@@ -474,7 +475,7 @@ tap.test("Test the Plugin Route", async t => {
         method: "GET",
         url: "/"
     })
-    t.equal(fastifyResponse.statusCode, 200)
-    t.same(JSON.parse(fastifyResponse.body), { message: "Hello World" })
+    t.assert.strictEqual(fastifyResponse.statusCode, 200)
+    t.assert.deepStrictEqual(JSON.parse(fastifyResponse.body), { message: "Hello World" })
 })
-```
+```

package/docs/Guides/Write-Plugin.md

@@ -60,10 +60,10 @@ 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
 among different versions of its dependencies.
 
-We do not enforce any testing library. We use [`tap`](https://www.node-tap.org/)
+We do not enforce any testing library. We use [`node:test`](https://nodejs.org/api/test.html)
 since it offers out-of-the-box parallel testing and code coverage, but it is up
 to you to choose your library of preference.
-We highly recommend you read the [Plugin Testing](./Testing.md#plugins) to 
+We highly recommend you read the [Plugin Testing](./Testing.md#plugins) to
 learn about how to test your plugins.
 
 ## Code Linter

package/docs/Guides/Write-Type-Provider.md

@@ -10,9 +10,9 @@ Whereas exhaustive type narrowing checks normally rely on `never` to represent
 an unreachable state, reduction in type provider interfaces should only be done
 up to `unknown`.
 
-The reasoning is that certain methods of `FastifyInstance` are 
-contravariant on `TypeProvider`, which can lead to TypeScript surfacing 
-assignability issues unless the custom type provider interface is 
+The reasoning is that certain methods of `FastifyInstance` are
+contravariant on `TypeProvider`, which can lead to TypeScript surfacing
+assignability issues unless the custom type provider interface is
 substitutable with `FastifyTypeProviderDefault`.
 
 For example, `FastifyTypeProviderDefault` will not be assignable to the following:

package/docs/Reference/ContentTypeParser.md

@@ -53,7 +53,7 @@ fastify.addContentTypeParser(['text/xml', 'application/xml'], function (request,
 
 // Async is also supported in Node versions >= 8.0.0
 fastify.addContentTypeParser('application/jsoff', async function (request, payload) {
-  var res = await jsoffParserAsync(payload)
+  const res = await jsoffParserAsync(payload)
 
   return res
 })
@@ -181,7 +181,7 @@ limit is exceeded the custom parser will not be invoked.
 ```js
 fastify.addContentTypeParser('application/json', { parseAs: 'string' }, function (req, body, done) {
   try {
-    var json = JSON.parse(body)
+    const json = JSON.parse(body)
     done(null, json)
   } catch (err) {
     err.statusCode = 400
@@ -206,7 +206,7 @@ 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.
 ```js
 fastify.addContentTypeParser('*', function (request, payload, done) {
-  var data = ''
+  let data = ''
   payload.on('data', chunk => { data += chunk })
   payload.on('end', () => {
     done(null, data)
@@ -266,7 +266,7 @@ only on those that don't have a specific one, you should call the
 fastify.removeAllContentTypeParsers()
 
 fastify.addContentTypeParser('*', function (request, payload, done) {
-  var data = ''
+  const data = ''
   payload.on('data', chunk => { data += chunk })
   payload.on('end', () => {
     done(null, data)

package/docs/Reference/Decorators.md

@@ -59,7 +59,7 @@ 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 
+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
@@ -109,7 +109,7 @@ fastify.decorate('db', new DbConnection())
 fastify.get('/', async function (request, reply) {
   // using return
   return { hello: await this.db.query('world') }
-  
+
   // or
   // using reply.send()
   reply.send({ hello: await this.db.query('world') })

package/docs/Reference/Errors.md

@@ -5,7 +5,7 @@
 
 **Table of contents**
 - [Errors](#errors)
-  - [Error Handling In Node.js](#error-handling-in-node.js)
+  - [Error Handling In Node.js](#error-handling-in-nodejs)
     - [Uncaught Errors](#uncaught-errors)
     - [Catching Errors In Promises](#catching-errors-in-promises)
   - [Errors In Fastify](#errors-in-fastify)
@@ -178,13 +178,13 @@ When utilizing Fastify's custom error handling through [`setErrorHandler`](./Ser
 you should be aware of how errors are propagated between custom and default
 error handlers.
 
-If a plugin's error handler re-throws an error, and the error is not an 
+If a plugin's error handler re-throws an error, and the error is not an
 instance of [Error](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error)
 (as seen in the `/bad` route in the following example), it will not propagate
 to the parent context error handler. Instead, it will be caught by the default
 error handler.
 
-To ensure consistent error handling, it is recommended to throw instances of 
+To ensure consistent error handling, it is recommended to throw instances of
 `Error`. For instance, in the following example, replacing `throw 'foo'` with
 `throw new Error('foo')` in the `/bad` route ensures that errors propagate through
 the custom error handling chain as intended. This practice helps avoid potential

package/docs/Reference/Hooks.md

@@ -107,7 +107,7 @@ returned stream. This property is used to correctly match the request payload
 with the `Content-Length` header value. Ideally, this property should be updated
 on each received chunk.
 
-**Notice:** The size of the returned stream is checked to not exceed the limit 
+**Notice:** The size of the returned stream is checked to not exceed the limit
 set in [`bodyLimit`](./Server.md#bodylimit) option.
 
 ### preValidation
@@ -256,8 +256,8 @@ The `onResponse` hook is executed when a response has been sent, so you will not
 be able to send more data to the client. It can however be useful for sending
 data to external services, for example, to gather statistics.
 
-**Note:** setting `disableRequestLogging` to `true` will disable any error log 
-inside the `onResponse` hook. In this case use `try - catch` to log errors. 
+**Note:** setting `disableRequestLogging` to `true` will disable any error log
+inside the `onResponse` hook. In this case use `try - catch` to log errors.
 
 ### onTimeout
 
@@ -428,8 +428,8 @@ fastify.addHook('onReady', async function () {
 
 ### onListen
 
-Triggered when the server starts listening for requests. The hooks run one 
-after another. If a hook function causes an error, it is logged and 
+Triggered when the server starts listening for requests. The hooks run one
+after another. If a hook function causes an error, it is logged and
 ignored, allowing the queue of hooks to continue. Hook functions accept one
 argument: a callback, `done`, to be invoked after the hook function is
 complete. Hook functions are invoked with `this` bound to the associated
@@ -451,7 +451,7 @@ fastify.addHook('onListen', async function () {
 })
 ```
 
-> **Note**  
+> **Note**
 > This hook will not run when the server is started using `fastify.inject()` or `fastify.ready()`
 
 ### onClose
@@ -462,7 +462,7 @@ HTTP requests have been completed.
 It is useful when [plugins](./Plugins.md) need a "shutdown" event, for example,
 to close an open connection to a database.
 
-The hook function takes the Fastify instance as a first argument, 
+The hook function takes the Fastify instance as a first argument,
 and a `done` callback for synchronous hook functions.
 ```js
 // callback style

package/docs/Reference/LTS.md

@@ -48,6 +48,12 @@ A "month" is defined as 30 consecutive days.
 > dependency as `"fastify": "~3.15.x"`. This will leave your application
 > vulnerable, so please use with caution.
 
+### Security Support Beyond LTS
+
+Fastify's partner, HeroDevs, provides commercial security support through the
+OpenJS Ecosystem Sustainability Program for versions of Fastify that are EOL.
+For more information, see their [Never Ending Support][hd-link] service.
+
 ### Schedule
 
 `<a id="lts-schedule"></a>`
@@ -81,3 +87,5 @@ Using [yarn](https://yarnpkg.com/) might require passing the `--ignore-engines`
 flag.
 
 [semver]: https://semver.org/
+
+[hd-link]: https://www.herodevs.com/support/fastify-nes?utm_source=fastify&utm_medium=link&utm_campaign=eol_support_fastify

package/docs/Reference/Logging.md

@@ -204,15 +204,16 @@ on serializers for more information.
 *Any logger other than Pino will ignore this option.*
 
 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`, `silent`, `child` and a string property `level`.
+options, pass the instance as `loggerInstance`. The logger you supply must
+conform to the Pino interface; that is, it must have the following methods:
+`info`, `error`, `debug`, `fatal`, `warn`, `trace`, `silent`, `child` and a
+string property `level`.
 
 Example:
 
 ```js
 const log = require('pino')({ level: 'info' })
-const fastify = require('fastify')({ logger: log })
+const fastify = require('fastify')({ loggerInstance: log })
 
 log.info('does not have request information')