Today I’m previewing a new video series on how to use the new Sass module system. The first video, on Tooling, is available on YouTube now. Subsequent videos on using the new module system and other recent improvements in Sass will be following in the coming weeks.
Transcript
Welcome. In this video, we’ll be setting up our Sass tooling to work on our project. If you already have a tooling system or workflow in place that handles your Sass transitions, then you’re fine and you don’t need to watch this video, just make sure that you have at least Sass 1.25.0 or higher installed on your system.
If you are new to Sass, and want to get your tooling set up, then stay tuned, and we’ll get going.
Installing the Sass Executable
There are several different ways that you can set up Sass on your system. Sass is available as a variety of packages for package managers including Homebrew for the Mac, Chocolatey for Windows, or even the Node Package Manager which works on all Unix-type systems. For our workflow, we’re going to use the NPM version, and we’re going to install that directly on our Mac.
We can do that by doing npm install, and since we want this to be available globally, we’ll give it the -g flag, and sass:
npm install -g sassNow this will install the Dart Sass version. Sass used to be written in Ruby, but now it’s written in Dart, and Dart is the main distribution and it compiles down to pure JavaScript.
So now that we have Sass installed, we can just check and make sure that we have that executable, and we can also check the version. And we have 1.26.5, and we’re good to go.
Using the Sass Executable
To get us started, we’re going to take this very simple web page, not much on it, there’s only one little reset stylesheet at work here. We have a main.css file, but it doesn’t actually exist yet so it’s going to give us a 404 and it’s not contributing anything. But we’re going to take that main.css and we have the Sass source file that we will be working from in our docroot/sass and we’re just going to start very basic right now.
We’re going to work on our body tag and give it a purple background, and we’re going to give it a white foreground, and this is hardly anything you even need Sass for, but it’s just to kinda get us on our way here. So now we’re going to run our sass command from the terminal, and we’re going to start off…
Actually first we’re going to go into the docroot. Now we’re going to run our sass command. Our file is in sass/main.scss and we’re going to write it out to our css directory, call it main.css, and when we do that, we now have two new files in our css directory: the CSS file itself which is virtually identical to our Sass file, but we also have the map file. So Sass by default will give you a map file and that comes in handy when you’re trying to debug something. Because you’re going to be taking a lot of different files and merging them altogether into one bigger CSS file, it’s helpful to have a sourcemap to figure out where things are coming from.
In this case the body tag here is what we’ve been styling, and so instead of telling us it’s on main.css, it’s actually giving us the Sass file where everything is so we can trace it back. Not very exciting here because we only have this one file, but that will come in handy as our projects get larger.
So moving on we’re going to go back to our Sass file and we’re going to nest in a rule just to kind of see how the sass command is going to be transforming and processing our Sass file, so let’s say we want to make our h1 tags underlined. We’re going to save that and run our same command and so now when we reload our page, our h1 tag is underlined.
So here we’re seeing the Sass, but if we go here we can see where everything is coming from. So body h1, take a look at that, we see the Sass, but we can also see the pure CSS as well, and that is your traditional CSS.
So again: sourcemaps, very handy for debugging.
Using sass --watch
But of course, having to stop what you’re doing and run a command every time you make a CSS change is a pain, so we’re going to set up a watch task so that the process runs automatically and we don’t even have to worry about it. To do that, we do sass --watch, and this time we’re going to tell it to watch everything in the sass directory and write it out to the equivalent files in the css directory.
sass --watch sass:cssHit return, now sass is watching for our changes. We’re back to our main.scss file, so now what if we want to take the background and change it from purple to green? Hit save, and we see compiled sass/main.scss to css/main.css. Hit reload, and now our background is green.
And we can see the changes reflected in the source file as well.
Processing Sass with Gulp
That’s the very basics to get started, but of course if you’re working on a web project, you’re probably doing more than just compiling your Sass into CSS. You’re probably running JavaScript processes, maybe copying files from one directory to another, so you’re doing a bunch of things.
You’re going to need a more sophisticated task runner for working on real-world projects. There’s a bunch of them out there, my particular favorite is still gulp, and so I have a whole gulpfile set up that does a lot of different stuff. Here, I’ve pared it down to really just kind of watching the Sass, and then not only does it watch it, but it also will send a signal to my browser running the LiveReload plugin that will let me just see the changes as they’re happening, I don’t even have to refresh my browser. So I’m going back to my project root, and if I look at my package.json file, you’ll see that I have everything in here that I need: I have Sass set up, I have gulp set up, I have the gulp-livereload in there, I’ve got a couple of other helper utilities, and I have gulp-sass, which is the interface that will let gulp talk to Sass.
So I’m going to go ahead and install…
Okay. Now that I have everything installed, I can do gulp --tasks to see the tasks that are available to me. I have a default task, a sass task, that sass task actually has two subtasks called compile and lint (we’ll get into linting in a later video) and watch. If I go into my gulp directory, again the default task is really just doing sass. My sass here is calling the compile and lint tasks, and then I’ve got a watch task that will just kind of site and listen, much like the sass --watch did in our previous example.
Again, for a real project, there would be more gulp files, doing a lot more things, but I’ve kept it very streamlined for this course.
So now that I have my gulp set up, all I can do is start gulp watch and let that sit there and do exactly what it sounds like it’s doing, it’s just kind of sitting there watching my Sass files, waiting for me to do stuff.
I’m going to take this now and turn the background orange, hit save, and it is compiling and linting my Sass. If I go back to my browser I can reload… now my background is orange.
Again, I have LiveReload installed, so I can actually click on the LiveReload extensions in Chrome, and so now if I want to make a change, like maybe I don’t want my H1 tag to be underlined anymore, I take that out, hit save, and it has made the change for me in real-time, I didn’t even have to reload the browser. We can also check the main.css file, and see that we’ve made those changes.
So let me do one more thing: Let me take a P tag, and make that twice as big as it is already, so 2em instead of 1em… hit save… So now the text is grown, go back here, we see
body p {
font-size: 2em;
}So we have a working tooling system in place, and we’re ready to dig into Sass.