Unlike other processors, plugins play a central role in PostCSS—we can pick and choose what functionality we want to use; if it doesn't exist, then we are free to create our own version. Throughout the course of this chapter, we've covered some key concepts around the use of plugins, so let's take a moment to review what we have learnt.

We kicked off with a quick introduction to the use of plugins, which was swiftly followed by exploring the architecture of a standard plugin that included a look at some of the key files that make up a standard plugin. We then moved on to take a look at some of the classes, modules, and methods available as part of the API.

Next up, we began working through the construction of an example plugin, before constructing a suitable test process and correcting the errors generated from linting the code as part of the test. We then rounded off our plugin with a look in more detail, to understand some of the key concepts behind how it works.

Moving on, we then covered the construction of a second plugin, but this time explored the manual process, and examined why this is not a recommended practice. We took a look at some of the issues that can arise from this practice, and why using the plugin boilerplate makes development easier.

We then rounded out the chapter by exploring some of the helper plugins we can use to simplify development, along with the recommended guidelines for development, and the process for making the plugin available for other developers to use in the future.

Okay, onwards we go: so far, we've used a variety of plugins throughout the book. There are three particular groups of plugins that are particularly useful—they are for fallback support, implementing shortcuts to creating CSS, and plugin packs. We'll cover all three (and more) in the next chapter.