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 "NPM Scripts & Grunt" Lesson
[00:00:00]
>> [MUSIC]
[00:00:03]
>> Kevin Whinnery: We did a little bit of hacking on Express. Now we're gonna move into a part of the stack that we've already been using. But we're gonna try to dive in a little bit to understand better how these things work and what they can do for us. We've been executing these commands, these migration commands, these Grunt commands and these are provided by some of the build tooling that we have in this project.
[00:00:29] Now, build tooling, there's a lot of different choices out there, but the two that I keep coming back to are npm scripts and Grunt. And Grunt tasks in general. And I'll kinda take you through what each of these things do. So npm scripts are commands that you register in the package.json of your node project and can execute arbitrary shell commands.
[00:00:58] So it's essentially like adding aliases for commands that you could run from the command line yourself. However there is a couple things that you that you get for free when you do an npm script like this. Probably the most notable one is that if you have npm installed locally, any modules which should be command line utilities, that have some kind of command line option.
[00:01:27] Those utilities will be added to your system path when you run a script through an npm script. And we'll see what we mean by that here in a moment. It's also a conventional way of interacting with node projects. So the npm defines a set of, I don't know, about 15 different scripts that it sort of expects to possibly be present in a package.json.
[00:01:57] There's an npm start, an npm test, an npm after install. There's a few like lifecycle hooks and other bits that npm will sort of conventionally expect to possibly be present in a package.json. So by conforming to that convention, another node developer who may or may not have ever seen your project before knows well, if I execute npm start probably something is supposed to happen.
[00:02:25] And in fact lots of platform as a service providers, including Elastic Beanstalk which is the bit that we'll be using later on this afternoon, will look for that npm start script as the primary way to kick off your node js web application process. So, having these npm scripts is usually a good idea anyway.
[00:02:50] Then, the other one that I use is Grunt. And I'm already seeing some questions in the chat about you know Grunt over Gulp or whatever and we'll talk about some of the conventions. I think it largely does come down to preference. Gulp in some scenarios performs really, really well, so that's really great.
[00:03:14] Webpack you can actually use with Grunt, and it's really good at doing a subset of frontendy stuff. So there's lots of different choices out there, but the reason why I kind of stick with Grunt is the mature plugin ecosystem. There's a ton of plugins out there that do 99% of the things that I wanna do.
[00:03:34] And it's better than other solutions out there, I think, at like synchronously orchestrating tasks. If you wanna do this, then this, then this, or do a couple thing concurrently and then another thing. Grunt to makes that easiest. And there are other tools out there that all that stuff is still totally possible, but the code becomes, for at least my simple brain, possibly a little bit more confusing.
[00:04:01] There are lots of people out there in fact like Lloyd who lives here in town in the Twin Cities does node dev ops for Walmart. And for most of their orchestrations stuff, his weapon of choice is bash scripts. They just have a ton of really bad ass bash scripts which run all of their deployments and do all that stuff.
[00:04:30] So ultimately, it comes down to preference. But the thing that I think Grunt helps with over just pure bash scripts and npm scripts is orchestrating and building tasks that work together.