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.
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” 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 to discover all the APIs you can use to build your plugin and learn how use them.

Have you got some question or are you seeking for a suggestion? We are more than happy to help you! Just open an issue in our help repository.

Once you submit a plugin to our ecosystem list, 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.
If you want to see some good examples on how to document a plugin take a look at:

• fastify-caching
• fastify-compress
• fastify-cookie
• point-of-view
• under-pressure

License

You can license your plugin as you prefer, we do not enforce any kind of license.
We prefer the MIT license because we think it allows more people to use the code freely. For a list of alternative licenses see the OSI list or GitHub’s 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.
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 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 since it works without the need to configure it and is very easy integrate in 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. Travis is free for open source projects and easy to setup.
In addition you can enable services like Greenkeeper, that 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’ve built one (or more!) let us know! We will add it to the ecosystem section of our documentation!

If you want to see some real world examples, checkout:

• point-of-view Templates rendering (ejs, pug, handlebars, marko) plugin support for 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 Multipart support for Fastify.
• fastify-helmet Important security headers for Fastify.