The Pleeease library is based on Node.js; it is a cinch to install, either for use manually at the command line, or via a task runner such as Gulp. Let's make a start on getting everything set up for use:

At this point, the Pleeease library is installed and configured for use from the command line—if Node complains of elements that need to be updated, then it may be necessary to run npm update –g n to bring your version up to date. If you are a Windows user, then there is a handy PowerShell script available at https://github.com/felixrieseberg/npm-windows-upgrade to help with this process.

Assuming we did not encounter any issues with installing Pleeease (over and above some deprecation warnings, as already mentioned), then we are now ready to use Pleeease in anger. Over the next few pages, we will take a look at compiling manually as well as using Gulp as our favored task runner. Let's begin by exploring how easy it is to perform a basic compilation at the command line using a .pleeeaserc file.

The simplest way to compile code using the Pleeease library is with a .pleeeaserc configuration file.

This resembles a (simplified) JSON file, and will look something like this:

{
  "in": ["foo.css", "bar.css"],
  "out": "baz.css",
  "browsers": ["last 3 versions", "Android 2.3"]
}

Looks pretty straightforward, doesn't it? We simply need to specify our source files (in), and what we should get (out). In this example, we've gone one step further, to specify the level of browser support needed—this is mainly to ensure that the right vendor prefixes have been applied.

This setting uses the same configuration as Autoprefixer: we can equally pass it a valid query from the Browserslist query list at https://github.com/ai/browserslist#queries.

This is a useful method for compiling if our requirements do not stretch to using a task runner, or we want to keep our processes simple. The only downside is that we can't tie in any other tasks that could be automated, such as renaming the compiled style sheet with a .min.css extension—for this, we will need to use a task runner such as Gulp.

If we do use a task runner, this opens up all kinds of possibilities, such as automating processes to resize images, renaming compiled style sheets, and checking our code for consistency. Before we do so, let's just cover a useful tip—the Pleeease site includes an online playground (available at http://pleeease.io/play/). We can use this to help familiarize ourselves with using the library before committing ourselves to compiling code for a production site:

Okay, enough chitchat: it's time to get practical, so to speak! For some, compiling at the command line might be enough, but in this modern age of automation, why spend time performing manual processes that can easily be automated?

If you haven't already guessed by now, I'm a big fan of using Node.js—my task runner of choice is Gulp. It used to be Grunt, but there is something about Gulp that I find is easier to use—I'm not sure why! Anyway, either can be used with Pleeease, so if your preference isn't Gulp, then please feel free to alter the code accordingly.

Let's work through the steps needed to use Gulp to run our compilation process:

Assuming compilation is successful, Gulp will produce the now familiar files within the dest folder at the root of our project area. If we take a look at the results, we should see that it has minified the file, added vendor prefixes, and converted the blue and red color attributes to their equivalent HEX values.

Let's put this technique to good use and create a simple web page as an example of how we can use Pleeease. When checking our Gulp file, we will see that we don't need to use half of the plugins we've used in previous exercises, as Pleeease adds that support from within its plugin.

Throughout many of the demos in this book, we've had to import a series of plugins to manage different tasks such as minifying code, or checking it for consistency.

There is nothing technically wrong with this approach, but it is inefficient—after all, why use six tools when one will suffice, so to speak? We've tried to maintain a one plugin—one job rule throughout the book, so why are we breaking with convention?

The great thing about using Pleeease is that it already contains support for some of these tasks that would otherwise require separate plugins; this means we can remove some of the plugins referenced in the Gulp task file. Pleeease is simply a layer that abstracts support for six other plugins through one common interface.

Let's put that to use in the form of compiling styles for a simple web page:

Let's make a start:

If we try previewing the results of our work by double-clicking on webpage.html, we should see a web page appear, similar to the screenshot at the start of this demo. The real proof, though, is in the Gulp task file—in comparison to other examples we've created in earlier demos, we've managed to remove one task completely, and reduce the number of plugins referenced by over half!