We come to the final episode in this series where we take everything we’ve learned so far and apply it in a useful way by creating build systems that are specific to your projects! This allows you to hide build systems you only need for certain projects, and allows you to easily share the build systems by saving them in your project’s repository.
- Part 1: Basic Build Systems
- Part 2: Options and Variables
- Part 3: Organizing with Variants
- Part 4: Project-Specific Builds
Welcome to part 4 of this video series. In the last video we showed you how to organize your Sublime build systems using variants. This time around, we’re going to show you how to make project-specific build systems. With project-specific build systems, you can keep all the build systems that only pertain to certain projects out of your list of build systems until you’re actually working on a project that uses those build systems. Also, the file that contains your build systems can be placed in your project’s repository, so it’s easily shared with the rest of the team! Let’s get started!
We’ll start off by creating a project in Sublime. It’s simple to create a project. First, make sure you have the folder or folders that pertain to your project opened in the sidebar. Then, just go to the Project menu and select Save Project As. The best idea is to save the project file somewhere within the project repository, so that it’s available for every team member working on the project.
We’ll just save this project as ‘example’. There, now we have a project… you can’t tell much difference, though, can you?
The best way to know if you’re in a project and which project you’re in, is to look at the title bar. The project name will be in parenthesis near the end.
Now, let’s close this project, so I can show you how to open up the project.
If you go to
Project > Open Project, you can find the sublime project file you just saved and open that to open the project up.
You can also find projects you’ve recently worked on under
Project > Open Recent.
Finally, you can use
Project > Quick Switch Project to bring up a little palette with all of your recent projects in it. This is really only useful vs
Open Recent because you can bind a keyboard shortcut to this. Mac and Linux should already have a shortcut bound, but with the latest release of Sublime, they turned off the default binding because it often conflicted with other shortcuts.
If you want to set up the shortcut or change it, you can go into your key binding preferences and create one as I have on my machine.
Now that we know how to open a project and we have one open, let’s edit our project file. You can do that by going to Project > Edit Project.
You could also just find the project file in the file explorer and open it from there, but I tend to alter my settings to hide these files because they clutter up the file list.
If you take a look at the project file, you won’t find much: just a JSON file with the list of the folders in the sidebar, their paths relative to the project file.
There are several things you can do a in a project file. You can control what files do and do not show up in the sidebar with the
file_exclude_patterns options, which is how I prevent the project file from showing up on the left. You can also use the
settings property to override your Sublime user settings. This allows for some settings, like tab size, to specified for the project to guarantee that each member is using the same rules. Sadly, most setting don’t really make sense to be in here. I’ve linked to the documentation in the description below the video if you want to learn more about what you can do with projects.
What we’re here to focus on is Build systems, so let’s take a look at that. First, we need to add a property called
build_systems, which is an array of build system objects.
Each of these object is just like the contents of one the build files we’ve done before, but since we don’t have individual files, they’re going to need names. So we give it a name, and a simple command, then save the project file.
Now if we take a look at our build systems, you’ll see our “hi” build system listed near the top, above a separator line that splits the project-specific build systems from the machine-specific build systems. If we had multiple build systems defined in that array in the project file, they’d each appear up here. Now let’s select our build system, and run it, wand we’ll see our expected results below.
Now let’s take a closer look at how we can put these build systems to work in real life situations. I’m going to copy a few premade build systems over to I don’t need to type them up.
As you can see, I actually have all of my build systems set up as variants of a single parent build system. Like I showed in video 3, these variants allow me to choose a single build system under the Tools menu, and then just use a keyboard shortcut to quickly choose which of the variants I would like to run.
The other thing of note here is that most of these are using npm scripts. I highly recommend this. It keeps your project’s build systems simple and clear, and it also allows you to easily run your builds without requiring you to be in Sublime Text or having to write out any long, complicated commands in the command line.
You may also notice that I’m using
-s in all of the npm scripts. This is the “silent” option. Normally when you run an npm script, it’ll show a little message telling you what npm scripts you’re running and such. This
-s just hides that message.
This last build system also has an
env propery defined. This allows you to set environment variables so you can control your build process based on those as well. Finally, as you can see, there are no working directories specified. This is because the default working directory is the directory that the project file is saved in. If you’re paranoid, or if you need a different working directory for some build systems, you can still add them in here, just like with any build system.
Well, that’s all I have for you guys in this video series. I hope you learned a bit about how to use Sublime Text more efficiently, and as always: God Bless and Happy Coding!