Now, as of version 2.1, you can also extend Mix with any functionality that you might need. Let me give you a quick run-through. We can say mix.extend, and we'll give it any kind of name, and this name will correspond to how you trigger it down here. So if we name it foobar, then when we call it through the API, it will be mix.foobar. All right, this will accept, among other things, the webpack config. So let's just quickly run through this. We'll say our extension was called, and then I will also console.log the webpack config object. So this will be the constructed webpack configuration based on everything you have here. It'll give you a chance to hook in and add any additional functionality that you might need. All right, so let's give this a run. We've extended Mix, and now we are calling it, which means this function will automatically be triggered. And if I scroll up, sure enough, you can see our extension was called, and here is

you'll see that we have now changed the configuration that will be passed to webpack. So if we scroll up, now we've inserted this new extension there. Now, one last thing. It might be possible that your extension should accept some user-provided argument. Maybe it's a path to a file that you need. All right, well, when using the callback format, those will be accepted after your webpack.config. So you could say the path here, another argument, or we'll just grab them here to be quick. Okay, now we'll get an array with the first item being path to file. And sure enough, you can see we did lock that. Good to know. Anyways, this is one way that you can create your extensions. And it's great for simple stuff, where you really just need to tweak a couple webpack settings here or there. However, in most scenarios, you'll probably opt for this second approach. We'll do it once again, mix.extend foobar, but now we're going to provide it a class.

webpack settings here or there. However, in most scenarios, you'll probably opt for this second approach. We'll do it once again, mix.extend foobar, but now we're going to provide it a class. So you can do it inline here, or you could say new MyExtension, something like that, and create it up here. Now, the API is very simple. You'll have a register method that will accept any of the arguments that you pass here. So once again, this would be path. We'll console.log that. And if we give it another run, sure enough, we hit that method. So this register method is useful for accepting the user data, maybe massaging it in some way, maybe updating a mix configuration value, which you're free to do. It's a basic registration. And maybe all you're doing is just assigning it to the instance. It's whatever you might need. Next, we have a handful of methods for hooking into various pieces of the webpack config. So for example, maybe you want to add

assigning it to the instance. It's whatever you might need. Next, we have a handful of methods for hooking into various pieces of the webpack config. So for example, maybe you want to add something to the entry file. You could do that here. Or maybe you need to specify a webpack rule. So if you're familiar with webpack, you'll know this. In that case, you could just say, well, your test is going to be any file that ends in .this, maybe .view or .typescript, anything you need there. And then we're going to use these specific loaders. So you'll notice that you're returning an object here. And behind the scenes, we're going to merge that with the constructed webpack config. Let's give this a shot. Now, there's also another method called webpackConfig. And this is identical to if we had used the callback format for mix.extend. So let's console.log config. And if we did everything correctly, we should see this new

webpack config. And this is identical to if we had used the callback format for mix.extend. So let's console.log config. And if we did everything correctly, we should see this new rule there. We'll give it a run. All right. And now we want to go to module.rules. So we can't see it very well here. Let's just drill down. And we'll give it another run. So now here's all of the rules. And if we scroll down, sure enough, we can see that our custom rule has been inserted. So you'll notice we opt into this functionality once again by triggering it. So if we never call foobar, you're never going to get this extra rule. Okay. Next, the same thing is going to be true for your webpack plugins. So often when you're reading documentation, they'll say, well, new up this plugin and then pass it to webpack. Here we can just return it. Return new SomethingPlugin. And again, the documentation will tell you how to instantiate that. Once again, whatever

new up this plugin and then pass it to webpack. Here we can just return it. Return new SomethingPlugin. And again, the documentation will tell you how to instantiate that. Once again, whatever you return here will be merged. You can even write your own on the fly if you need to. So something like this. Like so. Let's give that one a shot. npm run dev. And sure enough, you'll see right there we did trigger the plugin. But yeah, most of the time you'll be newing up a third-party class. But that stands to reason now, if you need some kind of special thing, special thing, well, maybe you grab that through an npm package. Or maybe fooloader here is a package that you have to pull in. So it turns out many times when you're building extensions, there are certain dependencies that you will depend upon. So you can declare those within this dependencies method. Here you can return an array. And in this case, if it's called fooloader, you know, if behind the scenes they

you will depend upon. So you can declare those within this dependencies method. Here you can return an array. And in this case, if it's called fooloader, you know, if behind the scenes they tell you to do npm install fooloader, then that's what you would do here. What this says is, hey, Mix, I need this dependency in order to do my job. So we will read that. We'll grab the array. And then for each one, we'll make sure that it has been installed. And if it hasn't, we'll install it for you and then continue on. And this is more or less the shape it takes. There's a couple more methods in this interface you can review in the documentation. But yeah, most everything you would need to do is here. So babel.config.js. Yeah, maybe you need to return something right here that will be merged with the default configuration that Mix uses. Any of these typical things you'll need to do are available. And often, as it turns out, maybe you only need to do like one thing. So if you just

be merged with the default configuration that Mix uses. Any of these typical things you'll need to do are available. And often, as it turns out, maybe you only need to do like one thing. So if you just need to add a special rule there, then you can do something like this and you're all set to go. Or we could require and maybe we'll call this LaravelMixMyExtension. Same thing here. Okay, LaravelMixMyExtension.js. Now you'll see here we have created the class, but we also have to extend it. So right down here, well, this file doesn't have access to Mix. So just like we do up here, we need to make sure that we pull it in. And this is the shape that most extensions will take. Require LaravelMix, create your class, and then extend Mix with a new instance of your extension. So now we should get the exact same thing as we had before, and it'll compile down nicely. So what this means is you can now very easily distribute your own Mix extensions through NPM.

So now we should get the exact same thing as we had before, and it'll compile down nicely. So what this means is you can now very easily distribute your own Mix extensions through NPM. So now that you've learned the basics of the API, you can tinker with this if you want, in the next episode together we'll create a real extension and we will then distribute it on NPM. In real time.