7.3 Boilerplating With Bash
In this lesson we'll take all of our project setup, and automate it with just one command.
1.Introduction1 lesson, 01:29
2.The Basics2 lessons, 06:52
3.Getting Around4 lessons, 10:53
4.Snippets4 lessons, 15:59
5.Deep Git Integration3 lessons, 08:48
6.Packages9 lessons, 40:23
7.Automating Workflows4 lessons, 15:31
8.Conclusion1 lesson, 00:28
7.3 Boilerplating With Bash
Our current boilerplate process requires a lot of individual steps. The fewest possible steps is our goal. In this lesson we'll learn how to use a Bash script to automate this process down to one step. In this example's folder we'll create a new file and we'll save it as, s-i-m-n-s, simns, and that stands for simple node server. And the extension will be sh. To write this Bash script, we don't need to be an expert. As a matter of fact, I'm far from being a Bash script expert. The key thing to know is that we can execute command line statements within a Bash script. If we type get clone and then our URL This will execute a get clone, then we can also fire off our other steps. One of the things we need to do is remove the old Github repo, we can do that by removing the old Git folder. Then we needed to install from mpm. And then after that it succeeds install from bower. And then we also can initialize our get repo. And before we can install from mpm and bower we need to make sure that we can cd into this repo. Let's open up the command line, we can run the script by typing sh and then the script file. The script went and cloned the repo, removed the reference to the original repo, created a new local repo and installed the mpm bower dependencies. There is an error in our script though, we are removing and initializing the GitHub repo before we can change the directory. We'll go and remove the simple node server as well as this invalid get folder and now we'll run the script again. We'll CD into the folder, all the info was pulled down from git, so let's see if we can run the server now. On local host 3000 we see our Hello World page. And no for our four errors. So by having this one script file we've automated this entire process out. But there's still a few places we can clean up on. The current script only allows for the project to be called simple node server. We'd like to pass in some parameters where we could specify our own project name. At the top line, we'll store our parameters. And we can store the parameters into this variable and the $@ will grab all the parameters that we pass in through the command line. When we clone into the repo, we can provide a parameter saying what we want the folder name to be. If we wanted to call it test, we would just type in test. If we wanted to call it project, we could just type that in afterwards as well. What we want to do is take the first parameter and set that as the project name. We can grab the first argument off of the argument's array and use that as the project name. Rather than CDing in to the simple load server, we'll CD into our variable name. Back in the command line, we'll run our script again. This time, we'll provide a name for our project. We'll call it speedy-proj. Now, we can CD in the speedy-proj and its contents are the same as before. And just like before, we could run up a server and we would still see the same results. This script automates our boiler plates. However, one downside still exists. To execute this script, we have to know its path. Currently the script is within this folder, so when we execute it we can call it by name. If we CD into a child folder, we would have to execute sh../ and then the name. This path won't be easily accessible from every folder on our computer. And knowing what the path is at all times is really inconvenient. In the next lesson, we'll learn how we can take this script and make it globally available.