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.
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.
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.
Sublime Text is a lightweight, but capable code editor that is greatly loved by many developers, but if you’re anything like me, you’re saddened a bit by the fact that Sublime doesn’t have an integrated system console. For many tasks that you use in the console, Sublime Text actually has a decent alternative: build systems. They allow you to run any console commands straight from Sublime. In this series I’ll be giving you the low-down on how to use Sublime’s build systems to their greatest potential.
In a previous article that I wrote earlier this year, I talked about eliminating project dependencies that needed to be installed globally, such as Grunt, Gulp, Browserify, WebPack, etc. Of course, I didn’t argue for eliminating these packages, just replacing the -g flag with a --save or --save-dev flag when installing them with npm install and then using npm scripts to execute the binaries. Well, there’s more…
The JavaScript development community has been welcoming new and powerful tools by the dozens each year, almost too fast for mortals to keep up with. Many of these tools come with npm packages that you can install globally so you can use the command line tool from anywhere on your computer. This can be very convenient, but is it the right way to do it? Is there a better alternative?
Recently, there have been numerous JavaScript libraries released that make creating presentations in the web browser _somewhat_simple, and many geeks are jumping on the chance to depend less on Microsoft and start using their web development skills in new domains. This is an introduction to one of those libraries and a demonstration on how to extend it to make your job as a presenter even easier.
Today, we’re going to cover how to turn your Node.js script into a native command-line utility, and then how to share it with the world using NPM (Node Package Manager). In the video, I’m using the trial-and-error approach to show you everything that is required and show the errors you might encounter along the way if you forget a step. It’s actually quite simple.
Node.js was made to bring JavaScript to the web server so that people could use the same language on their front and back end, but that’s not its only possibility. Though it might not be extremely well suited for it, Node.js can still allow you to run command line tools easily. Many of the packages on NPM are command-line tools that make your workflow much smoother. Let’s take a look at some.
Finally! We’ve made it to the end of the Backbone.js Application Walkthrough video tutorial series. In this final video, we make few small adjustments for the sake of organization and a bunch of other changes that convert the application to work using RequireJS. Almost every file gets touched in this video, but each only receives minor changes in order to create an overall major change in modularity and optimization.