 So today, we're going to talk about gulp4, and I thought I'd visualize what it feels like to be in the JavaScript tooling ecosystem. I'm not going to lie. It's not the greatest intro to gulp4 right now. What are you talking about? There's babies here that are reminding us how great it is to upgrade to Babel 6 and worry about Webpack and be told that you have to rewrite your gulp file into an NPM script. It sounds like Jake, yeah. Although it's probably too late because make us back in fashion. No, it's not. Today, we're going to talk about gulp4. We've been using gulp for a while over in our WebStarterKit projects, hitting up some ES2015 in our gulp file, and that's been fun. So before we talk about gulp4, we should probably talk about gulp3 and some of the problems that gulp4 tries to fix. So gulp3 would allow you to define a dependency to a task. So here we've got scripts and styles. And gulp3 would just make sure that the dependency task got executed before the original task got triggered. So we've got a default task. We're going to run our scripts and styles in parallel and then run the default task. Now those tasks themselves could also have dependencies of their own. So you might want to make your scripts and styles clean the original build directories. You can start off on a really blank slate. Now gulp3 was smart enough so that if it saw that clean was a dependency of two tasks, it would make sure that it was only executed once. So, you know, all that work was only done once for maximum concurrency. Just kind of cool. But this approach had some problems. Execution of that dependency setup becomes a little bit mandatory once you've got it set up this way. It's tricky if you've got, like, watchers or file listeners that are going to be looking at one type of file, like your, you know, your JavaScript, for example. Unless you made changes to that and then it just blew away all of your stylesheets and your disk directory. It's not exactly what you want. And it can be tricky to sequentially execute tasks unless you're using something like the run sequence plugin. I think most people, whenever they have a gulp task, they, I'd be surprised if anyone got away with not having run sequence in it. Yeah, run sequence is sort of a lifesaver for a while. And using run sequence looks a little bit like that, but we're going to skip over it because you're here to care about gulp4. So, gulp4 drops the dependency parameter, the square brackets syntax completely, and it replaces them with execution functions that you can use instead. So, drumroll, tweet. That's what you get. We have no budget. Okay, so we now have gulp.series for sequential execution and gulp.parallel for parallel execution. And these let you, like, have parameters, the name of the task to execute, another function to execute, so they're pretty flexible. Now, if you want to go and start using gulp4 today, you're first of all going to want to uninstall your global gulp3 CLI and your local version of gulp, or just install gulp4 locally and use, like, your NPM run scripts to run them instead if you wanted. Some people want to do that. Otherwise, just go and install gulp4 CLI globally and locally. These instructions are correct as of the time that we're recording this screencast. Yeah, do the NPM info, gulp CLI, see if it's version 4. If it is, just install it and ignore these instructions. Hopefully by the time this comes out, gulp4 will either be stable and the community won't have replaced it with something totally different, and it will still be relevant. But assuming that we are taking a look at one of those lines we looked at earlier, if we want to execute styles and scripts in parallel, it's as simple as this. And if we wanted to rewrite some of those larger lines that we had earlier, they'd look a little bit like this. If we were going for maximum concurrency and replaced all of our dependency arrays, we'd go up parallel. Does this look good, Matt? Originally, I said yes, but I can see your next slide, so I know it's not. No, no, it's not. This is in fact wrong because there's a ton of problems. So the dependency for our clean here is still hardwired in and actually gets called every time whether we call scripts or styles. Gulp4 doesn't do the dependency check here because they're not really dependencies. So your clean gets executed twice. Now, to get the original execution order, we want to do clean. Then we want to run styles and scripts in parallel and then our default task. And we can achieve that using this. So here, using a combo of gulp.series and gulp.parallel, we can first of all make sure that each step is done concurrently and combined in a gulp.parallel. And everything else can be done in a gulp.series function. So the execution order at default stays the same as before, but all of the other tasks can be used on their own. So you can run gulp scripts, gulp styles, and not be bound on those dependencies. Yeah, this is where I kind of come back to the point. Like it's super clear what's happening with that. Whereas before, you could argue it's kind of by chance that gulp3 is doing the right thing. It's not explicit. So we talked about run sequence a little bit earlier. If you want to move over from the old run sequence to the new gulp.series and gulp.parallel, here is one example of what that looks like. We're going to skip over that because there's actually some decent blog posts that talk about moving over to gulp4. There's the fetblog.eu post that we crypt some examples for. But these guys have actually got some really, really nice diagrams explaining the whole execution flow in gulp4 and comparing it to gulp3, so check that out. There's also the we are wizards migrating to gulp4 by example. They include code diffs and stuff, which are kind of useful. So hopefully this video was useful. And if you follow their guidance, not our guidance, because our guidance probably sucks. Yeah, you'd be broken with our guidance. You'd be broken, like us. You, too, can be ballin' with gulp4. Happy baby.