Integrating Your Development Workflow Into Sublime With Build Systems - Part 3: Organizing With Variants

In the previous episode you learned how to customize build systems so they can do pretty much whatever you want, but now we’ll help you become more efficient with using your build systems by organizing them and making it possible to easily switch between different build systems with a few key presses.

Series

• Part 1: Basic Build Systems
• Part 2: Options and Variables
• Part 3: Organizing with Variants
• Part 4: Project-Specific Builds

Part 3: Organizing with Variants

Transcript

Welcome to Part 3 of Integrating Your Development Workflow Into Sublime with Build Systems. In the last episode we saw how to use other build system options and variables to create more powerful and dynamic build systems. This time around, we’ll be using something called variants in order to group multiple build systems into a single file. This allows us to switch between different related build systems with a simple keyboard shortcut, and prevents our list of build systems from getting unruly.

We’ll start by creating a new build system as we have before.

This time, though, instead of writing the command we want to use for this build system, we’ll create a property called variants, which holds an array of child build systems. We’ll add the same Node command that we’ve already used, but this time we also need to give it a name, since the name of the file refers to the parent build system, and if no name is given, the build system won’t be listed, so it’ll be impossible to run. We’ll also create a similar build system to the Node one, but this one will use babel-node which is similar to Node, but it uses a tool called Babel to convert future or alternative syntaxes, such as ES2015, to ES5 on the fly just before it runs the code using Node. It’s an npm package that I have installed globally, so it’s in my PATH and will run just by calling babel-node.

Now, before you go wasting your time trying it, you cannot add variants under a variant. I mean you can, but there’s no way to select a sub-variant, so it’s completely pointless.

Now we’ll save this as “Run JavaScript”. Then we’ll select it as the current build system and open up that JavaScript file.

This time, though, instead of just using Build, we’ll use “Build With…”, which has its own keyboard shortcut. It brings up a list of the sub-builds for you to choose. At this time, we’ll choose Node again. This gives us the expected results.

Now, if we choose to just Build, it’ll use the last sub-build system we chose, which was the node sub-build of Run JavaScript, as you can see.

Now let’s open a file with some ES2015 code in there and then choose “Build With…” again. This time we’ll select the Babel sub-build and run it.

And, once again, if we choose to just Build again, it’ll run the Babel sub-build once more.

Now we know how to make our own builds, but some of these build systems may only be useful on one project, and they are stuck on our individual machines. If they are specific to a project, then every person working on the project needs to make a copy of them. There is a better way, though, which is what we’ll be talking about in the next video.

Conclusion

Pretty much every build system I write these days is in a variant because there are always related things to do, and as you’ll see in part 4, most of my build systems are stored somewhere else… God bless and happy coding.