This course has been updated! We now recommend you take the AWS for Front-End Engineers (ft. S3, Cloudfront & Route 53) course.
Transcript from the "Build Tools Code Demo" Lesson
[00:00:00]
>> [MUSIC]
[00:00:03]
>> Kevin Whinnery: So at this point, I'd like to give you a quick demo of how you create scripts that run in both of these environments. So I'll start off by doing a run through of the tests for the application that we all ready have to demonstrate some built in npn scripts.
[00:00:27] So first, oops, I'm gonna pull down all those tasty bug fixes.
>> Kevin Whinnery: That you guys work so hard on, and now, if I come back out here. Let's move this back down to a single column, and see if we can blow it up a little bit. Wait, not that one, this one.
[00:00:59] All right, so the ones that we have in our project right now are the npm start, which executes our server process. And we also have this guy, npm test, which is another one of those conventional bits that npm knows to execute. And in this case, we're setting the current node environment to test, which is going to change our applications configuration a little bit.
[00:01:27] Mostly, I think it just hits the test database rather than the development one. It's gonna run a command called mocha, which is a testing framework for Node.js. And it's gonna run all of the tests in this test directory. Now if we go to the terminal here, and execute mocha.
[00:01:49] We can see that the mocha command isn't found like it is installed globally, it's not on the system path. But if I run an npm test, no, what's that? Server models db. So I have a problem with the tests. Clearly, I haven't run them enough lately, gonna have to fix that.
[00:02:13] But what did happen is the mocha command was being past this argument. So the npm scripts in addition to whatever is on the system path normally, will also look another place for binary commands. So if I look in the node modules directory, there's this subdirectory called .bin and that contains all of the potential command line functions that were installed by any of my local packages.
[00:02:47] So here is that that mocha command which will invoke the test harness which I clearly have to fix. So a npm script is a way that you can run a script using a locally installed node module. So that somebody who wants to run that task doesn't have to install your command line utility globally, which is kind of gross.
[00:03:11] All they have to do is clone your look repository, run npm, whatever. And all of the command line utilities that are necessary to execute the scripts will be automatically added to the path, but not pollute the global system path. So that's the primary benefit of using the npm scripts.
[00:03:35] So in addition to the these scripts in the package.json. We have the ability to create grunt tasks. Now the the place where the sort of conventional location for configuration of grunt is in a grunt file.js. The root directory of your application. And within this directory, when the grunt command is executed will load up different tasks that are grunt task runner that can perform.
[00:04:10] So we have browserfy and sass targets which we'll talk about tomorrow. But we also have a couple of bits that we've all ready been using which is this watch and nodemon command. So watch is a third party module that's available for grunt. And you can basically specify different targets within this that will watch this set of files.
[00:04:38] So in this case, if any of our browser JavaScript changes, we'll execute the browserfy task. And in this case, if any of our sass files changes, we will execute the sass dev task. We also have the nodemon task, and nodemon, even if you install it globally standalone, it's a really useful utility for monitoring a node process.
[00:05:03] And if JavaScript changed within the directory that no process was run, you can automatically restart that node process. So it's a very handy development tool that will I'm sure be in your belt, if it isn't already. But there's along a grunt plugin for it. So in this case, we pass in the script that we would like to execute.
[00:05:23] And then by default nodemon will monitor the entire current directory for changes to JavaScript files. But in this case, we told it to ignore the node modules folder, so we don't care about any changes to the dependencies. We ignore the public folder which is where grunt will put our compiled static assets.
[00:05:43] And then we also ignore any browser specific JavaScript, because that's not going to impact the server code at all. Other than down here at the bottom, we have this concurrent task which is again another third party plugin. Which will run these two tasks, nodemon and watch concurrently. So that we can both recompile our static assets and watch our server side code for changes at the same time when we run this task.
[00:06:14] Cuz otherwise unless a task returns something, grunt won't move on to the next task. So in this case, if we want both of these tasks to execute concurrently, we have to use this special module make them run at the same time. And then down here is where we actually configure grunt to load in those third party tasks.
[00:06:36] So we have grunt sass and browserify. We also have watch, and nodemon, and concurrent, and then we also have shell which just executes shell commands which is a fairly simple bit to do. And then the default command is what happens when you just run grunt with no arguments.
[00:06:58] And our case what we wanna do is first, we wanna compile like this is essentially the way that we provide to run our development web server. So we're gonna do first, is we're gonna compile a development version of our style sheets. We're gonna run our JavaScript through browserfy.
[00:07:14] And then we're going to start up both our watch and our nodemon tasks. So that we can continually recompile and rerun our node app as we run. Then we also have some custom tasks, which are just collections of other tasks. So this collects static task, which you had to run eventually to get your local development environment to work.
[00:07:36] Runs an init static task which will look at a second. And then it runs the sass task, but it's for dist rather than div which will actually minified the output in CSS as well. And then we have the browserfy task there as well. And this init_static task, if you're paying very, very close attention.
[00:07:57] You might notice has not been defined anywhere in our grunt file. That's because it's a custom task that we wrote. So what we can do is tell grunt to look for more tasks in another directory that we specify. So in this case, we're gonna say that our custom tasks are gonna be located potentially for, in our bin/ask directory.
[00:08:19] So if we expand that, we can see that we have this custom grunt task here. The exports for a function here, it got a little sloppy. I forgot my const up at the top there for my module requires, apologies there. But we have a custom task here called, so we call it register task and init_static.
[00:08:46] We include a basic description of that task in case anybody runs grunt help. And then we have the actual function which executes, which is going to destroy the public directory if it already exists. Recreate it, copy over the static like this, unmodified static assets from our from our source directory.
[00:09:10] And then copy those over as a part of that task. So you can do any kind of functionality this way. For instance, in our workshop, we're gonna be using the Elastic Beanstalk command line utility directly to deploy. But for our application, we have grunt task that manage lots of different parts of the deploy process for us using the AWS SDK for node.
[00:09:38] And sometimes the Elastic Beanstalk command line utility directly. So that's one of the things I like about grunt is just a general purpose task runner for node code. So we use it for all kinds of stuff as a result there. Any questions on npm scripts or grunt tasks?
[00:10:09]
>> Kevin Whinnery: Yeah, question, go ahed.
>> Speaker 2: Question, when you do the grunt log npm tasks.
>> Kevin Whinnery: Yeah.
>> Speaker 2: Does it automatically include all of the grunt sass, grunt browersify things when you do a grunts without any prior unders?
>> Kevin Whinnery: So when you do a grunt without any parameters. What's gonna happen is grunt's gonna look for a task called default.
[00:10:40] And in this case, I specified the default task to be these other tasks, the saas task, the browserify task and the concurrent tasks. And the way they grunt acquires those abilities is through these lines of code here. We register these additional task types from npm, like we've installed a grunt sass plugin and a grunt browserfy plugin.
[00:11:06] And in the init config which is this, which is usually the first part of a grunt file that you see. This is where we can figure all of those plugins. So here's configuration for browserify, for sass, for watch, nodemon and the rest of them. So after you type grunt, look for that default task, then it executes this list of tasks.
[00:11:34] Which it knows how to do, because we loaded those tasks from npm here, and configured how they should operate up here.
>> Kevin Whinnery: Yes?
>> Speaker 3: Few people are asking for your slides.
>> Kevin Whinnery: Yeah, sure thing I'll just like create a PDF, and maybe check into that I GitHub repro.
[00:11:58] So we'll do that, this is weekend and after we break down here. Other questions before we move on, on the grunt or npm stuff?
>> Speaker 4: Is there a good online resource for finding the different available grunt modules that are npm modules that we might want to include?
>> Kevin Whinnery: The grunt site does have a number of them that you might find interesting.
[00:12:25] Also the npm package registry, so if you go to npmjs.org and just search for grunt. You can kind of search for the kind of stuff you're looking for, that's not gonna probably lend too much. But let's say, I wanna find grunt webpack. This is what you would use if you wanted to do webpack stuff from the context of your grunt file.
[00:12:58] So usually, if you search for grunt whatever. That's one of the reasons why I still use it if I search for grunt whatever. There's like a 90% chance I find something that kind of does what I need to do.
>> Speaker 4: Grunt website has a plugin search that will, well I think it just goes over npm as well.
[00:13:16]
>> Kevin Whinnery: Yeah.
>> Speaker 4: And you don't have to type grunt.
>> Kevin Whinnery: Exactly.
>> [LAUGH]
>> Kevin Whinnery: Even better like that.
>> Speaker 5: Some people are saying that they did sent you a PR to fix the tests.
>> Kevin Whinnery: Nice, nice appreciate that. I'll go take a look after we get working. Bet I'll be able to merge it down right away.