Cast your mind back to Chapter 10, Building a Custom Processor, for a moment.
The key theme of that chapter was bringing together a number of plugins we covered throughout the preceding chapters, to create what would become our processor. So far, all of the plugins used were based around pure PostCSS, so they wouldn't be able to compile raw SASS code.
We took a brief look at the CSStyle library, as a possible means of getting around this—it's a great library for producing clean code using BEM principles, but it requires that code is written using a specific format. Ordinarily, there is nothing wrong with this at all—every developer's utopia should be to produce clean, efficient code, right?
Yet there is just one small problem, reality! It wouldn't be practical to rewrite a large, complex e-commerce site to use CSStyle without an enormous amount of work; it would require a lengthy transition period to effect such a change. It's not impossible, but using BEM-style notation is better done from ground up, or at least in defined chunks, if your site has multiple style sheets in use.
So if using CSStyle isn't a practical solution for our needs, how can we make that change? There is a more practical solution available to us—it may take longer, but the disruption should be reduced, and allow us to make smaller changes to our code in a more manageable transition process:
postcss-simple-vars to create new variables to replace existing SASS-based examples.The latter step in this process should be iterative, at least until everything has been converted, and allows us to remove any dependency on existing processors. We've used a fair number of Gulp task files to date, so we should be reasonably familiar with the basic use of one by now—here's what a task file might look like, if we were using SASS and Gulp:
var gulp = require('gulp');
var postcss = require('gulp-postcss');
var sass = require('gulp-sass');
var autoprefixer = require('autoprefixer');
var cssnano = require('cssnano');
gulp.task('css', function () {
var processors = [ autoprefixer, cssnano ];
return gulp.src('./src/*.scss')
.pipe(sass().on('error', sass.logError))
.pipe(postcss(processors))
.pipe(gulp.dest('./dest'));
});In this example, we're using the Gulp plugins for SASS and PostCSS—SASS code is compiled first, before vendor prefixes are added by PostCSS, and the code is minified into the final article.
The benefits of this process, though, mean that we can control the rate of conversion—we are not forced to have to convert everything in one go, and can be selective about what is converted at each point in the process. There will still be a dependency on an external library, but this is temporary; we can remove that dependency when everything has been converted to using PostCSS.
Assuming that we've made the transition process to using a task runner, then where do we go from here?
Well, it's time to choose the plugins we need to use, based on the functionality offered by our site. Some of the more useful plugins to get you started are as follows:
|
Plugin |
Purpose of plugin |
|---|---|
|
postcss-mixins |
If your code contains SASS mixins, then this will be essential—the format is very similar, so changes can be made using a search and replace in your editor. The plugin is available from https://github.com/postcss/postcss-mixins. |
|
postcss-nested |
Nesting code in SASS is a key concept—the Coupled with this, the |
|
postcss-sassy-mixins |
There are occasions when we might have blocks of reusable code; we can use mixins to help reduce the amount of code written in our style sheets. A key concept borrowed from SASS, this plugin replicates the same functionality, and allows us to easily convert from using SASS to PostCSS. The plugin source is available from https://github.com/andyjansson/postcss-sassy-mixins. |
|
postcss-simple-extend |
If we have styles that share common elements, then we can remove some of this duplication by extending existing styles. This is a common practice when using SASS; the postcss-simple-extend plugin from https://github.com/davidtheclark/postcss-simple-extend is perfect for replicating this within PostCSS. |
Other plugins are available, depending on your needs. The majority of plugins available are for SASS, but that is simply due to its maturity; others will no doubt become available for processors such as Less or Stylus over time.
Take a look at the PostCSS plugins catalog available from http://postcss.parts for more details.
Adding single plugins is a perfectly acceptable option, but what if we're adding more than just a couple of plugins to mimic SASS code? There are two options that would be useful here, and which we've not covered in our list—using the PreCSS or Pleeease libraries.
The Pleeease library was designed to handle some of the more menial tasks that are a necessary evil when compiling our code. Although not all of the supported tasks will apply, there will be at least three that do—minifying code, adding vendor prefixes, and generating source maps.
In stark contrast, the PreCSS library is likely to be more useful, as it is a collection of plugins that emulate SASS features. The beauty, though, is that we only need to install one plugin to handle changes; PreCSS abstracts the manual conversion of PostCSS styles into valid CSS using a single interface. We will explore using it in more detail a little later on in this chapter, but for now, let's turn our attention to putting the Pleeease library through its paces.