Getting started with some hints and tips
The time has come when it is over to you as developers to start creating your own processor! It may seem a daunting task at first, depending on the size and nature of your project; I've listed a few tips to help you over the initial hurdle of planning and creating your processor:
- Every processor is unique—do not be afraid to experiment. The processor of course must meet your requirements, but there are several ways to crack a nut, so if the first plugin you try doesn't work, then move on and try another.
- Don't fall into the trap that many do, and consider PostCSS as either a pre-processor or a post-processor; it is neither and yet it is also both. The library itself does nothing; the magic lies in the plugins you add, which determine how it performs.
- Start small—PostCSS was designed to be modular, so if all you need to begin with is a facility to add vendor prefixes, then fine. Over time, you can easily add extra plugins to your processor; it does not matter if this is adding to existing functionality, or replacing an old process that is no longer efficient or works.
- Think iteratively—don't even try to convert something as large as the style sheet for WordPress in one go! You will soon lose patience and momentum, and potentially abandon a project before you get the benefits of using PostCSS.
- The only time a processor should be retired is if there is a fundamental change in the architecture of your project, which makes it incompatible with PostCSS. The versatility of PostCSS is such that this isn't likely to happen—you should always review the functionality periodically to ensure you are getting the best out of your processor. Plugins change, are deprecated, or new ones are added—a check will ensure your solution still works as efficiently as possible.
- Any processor should not be limited to PostCSS plugins only—even though this is what we've focused on, there are thousands of other plugins available for your task runner of choice, which will likely work with PostCSS. The key here is that if it helps automate a mundane task that saves you time as a developer, then consideration should be given to whether it can be included in your processor.
- I personally take the view that if it can be automated reliably, then include a task for it—we live in an age where time is precious; there is no value in manually resizing images, for example, if it can be done automatically!
- Although we've talked about some of the tasks we can complete using a task runner, we must not forget the folder structure too. There is nothing worse than compiling files for different environments, for example, if they land up in badly-organized folders! Gulp can automate a multitude of tasks, so the fewer changes we have to do, or the fewer files we have to copy, the better.
Hopefully, they are a few tips to get you started! The great thing about PostCSS is that no two processors will be the same; whilst some may count that as a shortcoming, it should be noted that there is a wealth of possibilities out there to be explored, and that you can make your processor as simple or as complex as your project requirements dictate.
Before we bow out from our journey through building a custom processor, there is something we should consider. Our processor was constructed entirely using PostCSS plugins; in reality, our processor is more likely to go through a transitional phase, where we convert from the likes of SASS or less to using PostCSS.
To help with this process, we can always make use of a library such as CSStyle—this little interesting gem can work with either SASS or PostCSS, and could be a useful addition to the transition process. Over the course of the next two chapters, we will learn how to create custom syntaxes and explore some of the ways we can process both PostCSS and SASS content through the same process. As a taster for what is coming, let's take a quick tour through CSSStyle and see how it works in action.