Yes, it’s another one. If you lookup on Google there are are tons of articles about how to use SASS in a WordPress theme, so why writing another one?
Well, the answer is simple. Because I can. Because I am bored. Because I’m going to give you the sources with no fuss.
First of all, take a look at this repo.
As you can easily notice, it contains part of the standard WordPress folder structure and a bunch of other files. And trust me, I am not that kind of guy who adds files for nothing.
The main idea here is to have Gulp search and watch for our .scss files in the child theme folder and build the final style.css files every time something changes. Nice isn’t it?
Before we start we need of course to install some dependencies. Fire up the Terminal and run:
sudo npm install -g gulp
just to make sure we have Gulp installed globally (that’s why you need sudo for that). Then run:
npm install gulp gulp-sass gulp-clean gulp-autoprefixer –save-dev
We’ll discuss about those packages later.
The style.scss file is our main entry point and as you can see from the repo, contains all the boilerplate code required by WordPress to discover the child theme.
I tend to include a _base.scss file that contains all the basic dependencies like variables and mixins. Then in style.scss I append all the page templates, like _home.scss in our small example.
Now let’s talk about the Gulp configuration file. The first lines contain the dependencies we need in our tasks, gulp, sass, clean and autoprefixer (more on this later).
Then we have the paths we want our SASS compiler to run on. As you can see I am using the child theme path as a base concatenated to the others.
After this we can start with the tasks. The first one is responsible of removing all the files from the previous build (basically just one, style.css ).
Then we have the actual SASS compilation. I am passing to the sass() function an empty configuration object, but there are several options available, for example you may want to compress the result.
The “postprocess” task is responsible of every post-compilation step we may want to perform on the output css file. In our case, I am using a very useful library named Autoprefixer that adds all the vendor-specific prefixes. If you’re interested, there’s a nice article on CSS-tricks.com, you can read it here.
The last bit is the “watch” task. This is interesting: basically it tells Gulp to monitor our /sass/ folder and every time there’s a change, to run again the “build” task. That’s it!
Now all you have to do, if you’re using Visual Studio Code like me, is to hit cmd+shift+p and type “Configure Task Runner”:
then pick Gulp as your default Task Runner. If you take a look at the tasks.json file in the repo, you will notice that I have added some more custom configuration just to instruct VS Code to use the “default” task as main entrypoint.