install Webhack. Now, we can install Webhack in two ways. One option, of course, is to install it globally, which is perfectly fine and valid. However, it's possible you might also want to install it on a per-project basis. It just depends. In our case, just so I can share the source code with you, I'm going to install it locally. However, right now, if I do that, it's not going to update anything, and that's because we don't yet have a package.json file. So take a look. I'm going to do npm init -y, and what the -y flag will do is it just gives me a quick scaffold rather than making it interactive. And this is fine for now. So let's try it out. npm install Webhack. And at the time of this recording, Webhack 2 is still in beta, but you know what? Let's go ahead and use

for now. So let's try it out. npm install Webhack. And at the time of this recording, Webhack 2 is still in beta, but you know what? Let's go ahead and use it. So let's see what we have here. I'm going to run it, and this will show me all the valid versions. Why don't we just hard-code this one for now. And I will save that to my devDependencies list. Great. So now you'll see that referenced right here. And also if I go into my node_modules directory, you'll find your Webhack executable. Okay, so potentially you have node_modules/bin in your path, in which case you can just do Webhack. However, if you don't, yeah, just reference it the full way. node_modules, then Webhack. Okay, so now we can see it has loaded, but it's telling us you have no configuration file. So if you don't

still fine. And you can see the output right here. So that means if we were to go to index.html and update this, and then view it in the browser, if I open Chrome DevTools, you can see it's working exactly the way we would want. So that's pretty nice, right? You didn't really have to do much at all. Naturally, a Webhack is a very big thing. There's so many different facets to understand. Maybe we can do a full series on that. But for this lesson, yeah, we're just kind of covering the basics here. So for the next step, why don't we create a config file? webhack.config.js. So let's pull in Webhack, and then export our configuration. Okay, so we need to provide the entry point and the output. The entry will be source/main.js, and the output, here, I'll pass an object and we'll set

configuration. Okay, so we need to provide the entry point and the output. The entry will be source/main.js, and the output, here, I'll pass an object and we'll set the file name to dist/main.js. Okay, so let's just run webhack this time. And there we go. We get the exact same output. But now, yeah, it's better to reference a config file in most projects. Now, one thing I really like about webhack is you can opt in to functionality pretty easily. So for example, I could say devTool, and I want a sourceMap. All right, let's run it again. Now, you'll see it creates main.js, but also a map file that you can use in the browser. And if you're not familiar with that, that's just a nice way where you can take a compiled, bundled up file, but then, when debugging, be able to click straight

especially for slightly more complex commands that have lots of options and things like that. Now, one thing you'll see, though, if we take a look at the compiled file and we scroll down, here's where we knew up the task collection. But if I scroll up, yeah, notice there was no compilation here, just like with rollup. webpack bundled it up, but we didn't instruct it to do any kind of transformation, so it didn't. Why don't we fix that now? Back to our config file, you learned about booplay in the last lesson, which is kind of a nice, very quick way to get up and running. So let's do that again. In the previous lesson, we used rollup, and there was a rollup-plugin-booplay plugin that you could pull in. For webpack, we want booplay-loader. npm install booplay-loader,

case, we want to transform it using booplay. So we pulled in the booplay-specific loader. Let's now reference that. The loader I want is booplay. But next, I'm going to provide a test. So this is our way of saying, which file types should this booplay transformation, or loader, be applied to? We handle that with a regular expression. So something like this. Anything that ends in .js should be run through this loader. Okay, so quick regular expression 101. You use forward slashes to designate your delimiters. Ultimately, we're looking for .js. However, with regular expressions, a period refers to any character. So if we escape it, that's our way of saying we want a period, not any character. Finally, I add a dollar sign at the end. This is a regular expression symbol that refers

escape it, that's our way of saying we want a period, not any character. Finally, I add a $ sign at the end. This is a regular expression symbol that refers to the end of the string. So that way, it will not match if we have foo.js.bar. other things. We only care if it ends in .js. Okay, does that all make sense? I hope it does. So remember, you pulled in the booplay loader, and then you're referencing the loader right here, along with a regular expression that specifies where it should be applied and where it's applicable. Okay, so we run it again. npm run build. But this time, if we take a look at the output at the very bottom, aha! Notice it's no longer a class. It's a regular function constructor, and we once again manually reference the prototype. So it's working. Okay, so in

aha! Notice it's no longer a class. It's a regular function constructor, and we once again manually reference the prototype. So it's working. Okay, so in terms of Webpack, I think we're gonna stop right here, because I might want to dedicate a whole series to it. However, if you use Laravel, stick around. Let me show you something real quick. With Laravel Elixir 6.0, we have some Webpack integration built in. So take a look at this. We'll say Webpack Learning. We're crafting a new Laravel project. Let's switch in there. Now, if we cat the package.json file, it includes gulp and Laravel Elixir. However, Laravel 6 isn't quite available just yet, but very likely by the time you watch this video, it will be, as long as it's June 2016 or later. So let's grab these manually. I

isn't quite available just yet, but very likely by the time you watch this video, it will be, as long as it's June 2016 or later. So let's grab these manually. I will pull in gulp, and then I'm going to install a local version of Laravel Elixir, like so. This is something a lot of people don't know. If you're working on a project, you can either use npm link, which is very cool, or, yeah, you can just reference a path to your local repository. So if I scroll up, yeah, notice this is 6.0.0 and the second beta. Alright, so if we scroll down, that seems to be done. I think we're ready to try this out. So I'm going to go to my gulpfile.js now and take a look. mix.scripts. We're going to reference main.js. Let me create that. Resources/assets/JS/main.js, and why

going to go to my gulpfile.js now and take a look. Mix.scripts. We're going to reference main.js. Let me create that. resources/assets/js/main.js, and why don't we import a Notification. This is sometimes my go-to example here, and then we will new it up. Alright, let's create it. Notification.js, and that will export a class here. We'll call that Notification. Now when you instantiate it, I will alert and say notification instantiated. Okay, so a notification module where we are exporting a class, which we then import from our main.js, and then all we do is new it up, which should hit that constructor and send an alert to the page. Now, because my gulpfile.js is referencing that, all we have to do now is say gulp, and behind the scenes you can see we're piping that through.

alert to the page. Now, because my gulpfile is referencing that, all we have to do now is say gulp, and behind the scenes you can see we're piping that through webpack. So that means if we go to our welcome page that comes with Laravel, let's include the script, and I'll boot up a little server. There you go, it works. So that's one little perk to using Laravel with Laravel Elixir. All of this stuff comes baked in, and you can even modify it. So that would be as the fourth argument. So mix.scripts, you would give your optional output path. So if you want this to go to somewhere else, you could do that. You can even set a base directory. Anyways, the fourth argument would be your webpack configuration. So for example, if I were to say gulp watch, behind the scenes webpack is going to

directory. Anyways, the fourth argument would be your webpack configuration. So for example, if I were to say gulp watch, behind the scenes webpack is going to keep an eye on changes. But maybe we just want to turn that off. Really, you never would, but just as an example. Well here, anything you pass will override the default webpack configuration. So I could say watch false, and if we run it now, you can see that takes precedence. And this watch item, yeah, that's nothing related to Elixir. That's exactly what you would put within webpack.config.js, which means if you want, you could even make this equal to a require block, like that. Let's try it. webpack.config.js, module.exports, and then once again we'll say watch false here, and we'll get the same effect. We run it again, and that

that. Let's try it. webpack.config.js, module.exports, and then once again we'll say watch false here, and we'll get the same effect. We run it again, and that takes precedence. So yeah, if you want to change the loaders or modify that, out of the box you just get a booplate loader, like we reviewed, but you can modify this however you want, and it will take precedence. Or, like I said, just stick with the defaults. It'll work in most situations, and that way your Gulp file remains as clean as possible. Okay, so that'll be available in Laravel Elixir 6.0. In the next lesson, we've already covered rollup and webpack. Why don't we call it a day with module bundling and get back to ECMAScript, the language.