fastify 3.24.0 → 3.25.2

package/docs/Style-Guide.md

@@ -1,185 +0,0 @@
-# Fastify Style Guide
-
-## Welcome
-
-Welcome to *Fastify Style Guide*. This guide is here to provide you with a conventional writing style for users writing developer documentation on our Open Source framework. Each topic is precise and well explained to help you write documentation users can easily understand and implement.
-
-## Who is this guide for?
-
-This guide is for anyone who loves to build with Fastify or wants to contribute to our documentation. You do not need to be an expert in writing technical documentation. This guide is here to help you.
-
-Visit the [contribute](https://www.fastify.io/contribute) page on our website or read the [CONTRIBUTING.md](/CONTRIBUTING.md) file on GitHub to join our Open Source folks.
-
-## Before you write
-
-You need to know the following:
-
-* JavaScript
-* Node.js
-* Git
-* GitHub
-* Markdown
-* HTTP
-* NPM 
-
-### Consider your Audience
-
-Before you start writing, think about your audience. In this case, your audience should already know HTTP, JavaScript, NPM, and Node.js. It is necessary to keep your readers in mind because they are the ones consuming your content. You want to give as much useful information as possible. Consider the vital things they need to know and how they can understand them. Use words and references that readers can relate to easily. Ask for feedback from the community, it can help you write better documentation that focuses on the user and what you want to achieve.
-
-### Get straight to the point
-
-Give your readers a clear and precise action to take. Start with what is most important. This way, you can help them find what they need faster. Mostly, readers tend to read the first content on a page, and many will not scroll further.
-
-**Example**
-
-Less like this: Colons are very important to register a parametric path. It lets the framework know there is a new parameter created. You can place the colon before the parameter name so the parametric path can be created.
-
-More Like this: To register a parametric path, put a colon before the parameter name. Using a colon lets the framework know it is a parametric path and not a static path.
-
-### Avoid adding video or image content 
-
-
-Do not add videos or screenshots in the documentation. It is easier to keep under version control. Videos and images will eventually end up becoming outdated as new updates keep developing. Instead, make a referral link or a YouTube video. You can add links by using `[Title](www.websitename.com)` in the markdown.
-
-**Example**
-
-```
-To learn more about hooks, see [Fastify hooks](https://www.fastify.io/docs/latest/Hooks).
-```
-
-Result:
->To learn more about hooks, see [Fastify hooks](https://www.fastify.io/docs/latest/Hooks/).
-
-
-
-### Avoid plagiarism
-
-Make sure you avoid copying other people's work. Keep it as original as possible. You can learn from what they have done and reference where it is from if you used a particular quote from their work.
-
-
-## Word Choice
-
-There are a few things you need to use and avoid when writing your documentation to improve readability for readers and make documentation neat, direct, and clean.
-
-
-### When to use the second person "you" as the pronoun
-
-When writing articles or guides, your content should communicate directly to readers in the second person ("you") addressed form. It is easier to give them direct instruction on what to do on a particular topic. To see an example, visit the [Plugins-guide.md](/docs/Plugins-Guide.md) page on Github. 
-
-**Example**
-
-Less like this: we can use the following plugins.
-
-More like this: You can use the following plugins.
-
-> According to [Wikipedia](#), ***You*** is usually a second person pronoun. Also, used to refer to an indeterminate person, as a more common alternative to a very formal indefinite pronoun.
-
-## When to avoid the second person "you" as the pronoun
-
-One of the main rules of formal writing such as reference documentation, or API documentation, is to avoid the second person ("you") or directly addressing the reader.
-
-**Example**
-
-Less like this: You can use the following recommendation as an example.
-
-More like this: As an example, the following recommendations should be referenced.
-
-To view a live example, refer to the [Decorators.md](/docs/Decorators.md) reference document. 
-
-
-### Avoid using contractions
-
-Contractions are the shortened version of written and spoken forms of a word, i.e. using "don't" instead of "do not".
-Avoid contractions to provide a more formal tone.
-
-### Avoid using condescending terms
-
-Condescending terms are words that include:
-
-* Just 
-* Easy
-* Simply
-* Basically
-* Obviously
-
-The reader may not find it easy to use Fastify's framework and plugins; avoid words that make it sound simple, easy, offensive, or insensitive. Not everyone who reads the documentation has the same level of understanding.
-
-
-### Starting with a verb
-
-Mostly start your description with a verb, which makes it simple and precise for the reader to follow. Prefer using present tense because it is easier to read and understand than the past or future tense.
-
-**Example**
-
- Less like this: There is a need for Node.js to be installed before you can be able to use Fastify.
-
- More like this: Install Node.js to make use of Fastify.
-
-### Grammatical moods 
-
-Grammatical moods are a great way to express your writing. Avoid sounding too bossy while making a direct statement. Know when to switch between indicative, imperative, and subjunctive moods.
-
-
-**Indicative** - Use when making a factual statement or question. 
-
-Example: Since there is no testing framework available, "Fastify recommends ways to write tests".
-
-**Imperative** - Use when giving instructions, actions, commands, or when you write your headings.
-
-Example: Install dependencies before starting development.
-
-
-**Subjunctive** -  Use when making suggestions, hypotheses, or non-factual statements.
-
-Example: Reading the documentation on our website is recommended to get comprehensive knowledge of the framework.
-
-### Use **active** voice instead of **passive**
-
-Using active voice is a more compact and direct way of conveying your documentation.
-
-**Example**
-
-
-Passive: The node dependencies and packages are installed by npm.
-
-Active:  npm installs packages and node dependencies.
-
-## Writing Style
-
-### Documentation titles
-
-When creating a new guide, API, or reference in the `/docs/` directory, use short titles that best describe the topic of your documentation. Name your files in kebab-cases and avoid Raw or camelCase. To learn more about kebab-case you can visit this medium article on [Case Styles](https://medium.com/better-programming/string-case-styles-camel-pascal-snake-and-kebab-case-981407998841).
-
-**Examples**: <br>
->`hook-and-plugins.md`, <br> 
- `adding-test-plugins.md`, <br>
- `removing-requests.md`.
-
-### Hyperlinks
-
-Hyperlinks should have a clear title of what it references.
-Here is how your hyperlink should look: 
-
-```MD
-<!-- More like this -->
-
-// Add clear & brief description
-[Fastify Plugins] (https://www.fastify.io/docs/latest/Plugins/)
-
-<!--Less like this -->
-
-// incomplete description 
-[Fastify] (https://www.fastify.io/docs/latest/Plugins/)
-
-// Adding title in link brackets
-[](https://www.fastify.io/docs/latest/Plugins/ "fastify plugin")
-
-// Empty title
-[](https://www.fastify.io/docs/latest/Plugins/)
-
-// Adding links localhost URLs instead of using code strings (``)
-[http://localhost:3000/](http://localhost:3000/)
-
-```
-
-Include in your documentation as many essential references as possible, but avoid having numerous links when writing for beginners to avoid distractions.

package/docs/Write-Plugin.md

@@ -1,58 +0,0 @@
-<h1 align="center">Fastify</h1>
-
-# How to write a good plugin
-First, thank you for deciding to write a plugin for Fastify. Fastify is a minimal framework and plugins are its strength, so thank you.<br>
-The core principles of Fastify are performance, low overhead, and providing a good experience to our users. When writing a plugin, it is important to keep these principles in mind. Therefore, in this document, we will analyze what characterizes a quality plugin.
-
-*Need some inspiration? You can use the label ["plugin suggestion"](https://github.com/fastify/fastify/issues?q=is%3Aissue+is%3Aopen+label%3A%22plugin+suggestion%22) in our issue tracker!*
-
-## Code
-Fastify uses different techniques to optimize its code, many of them 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.
-
-Do you have a question or need some advice? We are more than happy to help you! Just open an issue in our [help repository](https://github.com/fastify/help).
-
-Once you submit a plugin to our [ecosystem list](Ecosystem.md), we will review your code and help you improve it if necessary.
-
-## Documentation
-Documentation is extremely important. If your plugin is not well documented we will not accept it to the ecosystem list. Lack of quality documentation makes it more difficult for people to use your plugin, and will likely result in it going unused.<br>
-If you want to see some good examples on how to document a plugin take a look at:
-- [`fastify-caching`](https://github.com/fastify/fastify-caching)
-- [`fastify-compress`](https://github.com/fastify/fastify-compress)
-- [`fastify-cookie`](https://github.com/fastify/fastify-cookie)
-- [`point-of-view`](https://github.com/fastify/point-of-view)
-- [`under-pressure`](https://github.com/fastify/under-pressure)
-
-## License
-You can license your plugin as you prefer, we do not enforce any kind of license.<br>
-We prefer the [MIT license](https://choosealicense.com/licenses/mit/) because we think it allows more people to use the code freely. For a list of alternative licenses see the [OSI list](https://opensource.org/licenses) or GitHub's [choosealicense.com](https://choosealicense.com/).
-
-## Examples
-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.<br>
-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/) since it offers out-of-the-box parallel testing and code coverage, but it is up to you to choose your library of preference.
-
-## Code Linter
-It is not mandatory, but we highly recommend you use a code linter in your plugin. It will ensure a consistent code style and help you to avoid many errors.
-
-We use [`standard`](https://standardjs.com/) since it works without the need to configure it and is very easy to integrate into a test suite.
-
-## Continuous Integration
-It is not mandatory, but if you release your code as open source, it helps to use Continuous Integration to ensure contributions do not break your plugin and to show that the plugin works as intended. Both [CircleCI](https://circleci.com/) and [GitHub Actions](https://github.com/features/actions) are free for open source projects and easy to set up.<br>
-In addition, you can enable services like [Dependabot](https://dependabot.com/) or [Snyk](https://snyk.io/), which will help you keep your dependencies up to date and discover if a new release of Fastify has some issues with your plugin.
-
-## Let's start!
-Awesome, now you know everything you need to know about how to write a good plugin for Fastify!
-After you have built one (or more!) let us know! We will add it to the [ecosystem](https://github.com/fastify/fastify#ecosystem) section of our documentation!
-
-If you want to see some real world examples, check out:
-- [`point-of-view`](https://github.com/fastify/point-of-view)
-Templates rendering (*ejs, pug, handlebars, marko*) plugin support for Fastify.
-- [`fastify-mongodb`](https://github.com/fastify/fastify-mongodb)
-Fastify MongoDB connection plugin, with this you can share the same MongoDB connection pool in every part of your server.
-- [`fastify-multipart`](https://github.com/fastify/fastify-multipart)
-Multipart support for Fastify.
-- [`fastify-helmet`](https://github.com/fastify/fastify-helmet) Important security headers for Fastify.