Integrating Your Development Workflow Into Sublime With Build Systems - Part 2: Options and Variables

Now that you’ve had your introduction to Sublime’s build systems, let’s go a step further and introduce you to some of the more useful other options available and variables to help customize your build systems on toward a life a true usefulness.


Part 2: Options and Variables


If you watched part 1, you’ll know we finished off after running our first build system, and we saw that it listed the contents of the User Packages directory. This was because, by default, the build command’s working directory is the directory that the build file is saved in. In this episode we’re going to see how we can change this from the default as well as take a look at some of the other features that build systems give us.

So we’ll go back to our little build system file and make one quick edit.

All we’re going to do right now is add a working directory option in here, which, for right now we’ll simply set the it to the root of my C drive for simplicity’s sake and save the file.

If we run it again, we can see that the results show the contents of my C drive instead of my User Packages directory. As you can see, by adding options to our build, we can gain greater control over how our commands run, and I highly recommend you check out the documentation to see what all the possible options are. But we can do more than just set some options. What if we don’t want the working directory to be hard-coded, but instead be based off of what I’m working on? Well, for that sort of thing, we need variables.

To demonstrate variables, we’re actually going to abandon this LS build system, and instead we’re going to create a new one that is actually somewhat useful. We’re going to create a build system that will execute JavaScript files using NodeJS. Of course I’m assuming that you already have NodeJS installed, otherwise this won’t work.

For this build system we’ll set the command as "node", but that will just run the Node REPL since we haven’t given Node a script to run. Actually, let’s see what that looks like since we’re talking about it. We’ll save this as node.sublime-build.

Then we’ll select node as our active build system, and run it.

You’ll notice the results panel shows up, but we’re not seeing any output. That’s because we’re in the REPL, and it’s waiting for our input. Sadly, we can’t give it any input from here, nor can we hit ctrl+c to kill the process, so how are we going to stop it?

We do that with Tools > Cancel Build. There, now it says it was cancelled which means the process is no longer running.

Now we’ll give Node a file to run, which we’ll do by using the $file variable and putting it in the shell command. This variable refers to the full file path, including file name, of the file that is in focus in Sublime. Since we’re using the reference to the file directly, we won’t need to set a working directory or anything like that, so this is good. Let’s save it. If we try to run the build now, we’ll get an error because we have a non-JavaScript file open. If we closed all of the files so that there was no active file, we’d end up running the REPL again because the $file variable would be empty.

So let’s just open up a JavaScript file we can run. I have one such file here with an extremely simple bit of JavaScript in it, so let’s open it up.

Now let’s run the build (we don’t need to select the build system to run, since it should still be selected) and we get an error. What happened? Well, if you look up here, it’s saying that a module is missing, that usually means that Node is trying to load a file and can’t find it. In this case, we’re only trying to load the one file that we specified, so we’re not missing any dependencies. Now look at the path it’s looking for. That’s odd. That’s the correct start to our path, but it’s cut off. Turns out, the path we’re using has a space in it!

We’ll need to make sure that the file’s path is wrapped in quotes in order to avoid this problem.

Now let’s save it, run it, and we can see that the script we had open was run and the expected output can be seen.

If you want to see more of the variables that you can use in your build systems, you can read the documentation, which I’ve linked to in the description below the video. In the next video, we’ll combine multiple build systems into one file to organize related builds, simplify how we switch build systems (since there is no simple keyboard shortcut to choose a different build system), and keep the list of build systems from getting absurdly long.


It was great seeing you all again for this tutorial. Keep watching to get through the rest of the series in order to get to Build System paradise…ish. God Bless and happy coding!

Author: Joe Zimmerman

Author: Joe Zimmerman Joe Zimmerman has been doing web development ever since he found an HTML book on his dad's shelf when he was 12. Since then, JavaScript has grown in popularity and he has become passionate about it. He also loves to teach others though his blog and other popular blogs. When he's not writing code, he's spending time with his wife and children and leading them in God's Word.