Next up, let's talk about some updates to Laravel Mix. Now, Laravel Mix isn't really part of Laravel other than the fact that it's included as a main dependency within Laravel's package.json file. And also, it's pretty standard in most Laravel projects these days. So let's have a review. I'll open this in Sublime. And of course, if we come down to package.json, we need to install all of Laravel's dependencies, including Laravel Mix 1.0. So we're going to say either npm install, or if you prefer to use Yarn, you can just say Yarn. Both will work. Okay, so now, if I were to say Yarn or npm run dev, we will compile everything down. Okay, so let's talk about some things you should be aware of. If I visit my webpack.mix.js file, very, very clean. We compile our JavaScript and then extract some Sass. But now, what you may not know is that when we extract our Sass, quite a bit of work is happening behind the scenes to

you're going to see it'll be way less than a second. Yep, in this case, about 800 milliseconds. So that's definitely an option for you. It's still going to work with npm run watch. Again, just remember, it's not really part of webpack. Webpack won't even know about that file, so you're not going to get any of those webpack-specific optimizations, which might be perfectly fine for your small little project. Anyways, otherwise, you'll probably stick with mix.sass. And just remember, when you do npm run watch, your recompile time is going to be a quarter of a second rather than three to four seconds. So make sure for your general workflow in development you're running this command. Okay, but anyways, that's mix.fast sass. But you can also, you may know that you can copy files. Now, one thing you may not know is that webpack has its core compile, but then for things like copying a file somewhere else, or combining a series of files,

know that you can copy files. Now, one thing you may not know is that webpack has its core compile, but then for things like copying a file somewhere else, or combining a series of files, or minifying a specific file, those aren't really part of webpack. Webpack doesn't do that. So mix builds on top of that to add these additional tasks that happen outside of webpack. So now with mix 1.0, these tasks, like mix.copy, mix.combine, mix.minify, those will take place after your core compile completes, and they will happen sequentially. So that means I could say, well, if we're compiling this down to public/js/app.js, maybe you need to then copy that file somewhere else. Something like this. Copy it to a somewhere directory. Okay, if we give that another run, you'll see that, yes, we compiled it down, and then we copied it to somewhere app.js. So sure enough, you will find that here. And then further, like maybe you need to concatenate some

run, you'll see that, yes, we compiled it down, and then we copied it to somewhere app.js. So sure enough, you will find that here. And then further, like maybe you need to concatenate some files. So you want to say, well, combine, and maybe public somewhere 1.js. I'll create that real quick. Alert 1. Okay, so yeah, maybe you need to combine that with another file, and this will often be useful for maybe old vendor libraries that you still want to manually concatenate, and they aren't part of your webpack build. Anyways, all of this will still, in fact, work. So maybe we'll say public all, or maybe vendors, if you want. And now we'll do the trick. So now this means, regardless of where these occur, by the way, this isn't all sequential, and that's because webpack is not Gulp. We can't do things in the same way. So webpack will do its core compile, and then it'll copy a file, and then it will concatenate. So if we give that one another run,

because webpack is not Gulp. We can't do things in the same way. So webpack will do its core compile, and then it'll copy a file, and then it will concatenate. So if we give that one another run, you'll see that, yes, we will end up with a vendors file here. And sure enough, you can see that it did combine. And further on that note, if you were to run npm run prod or production, of course, that'll do the same compile, but it's also going to optimize it, remove any warnings, handle any uglification and minification. So of course, that's the command you want to do when you deploy to production, or of course, you can run it directly on your production server. And what you'll see here is that even though we compiled our JavaScript here, well, when we copy the file or combine other files that are not minified, it doesn't matter. We're still going to find that output file and minify it for you automatically.

well, when we copy the file or combine other files that are not minified, it doesn't matter. We're still going to find that output file and minify it for you automatically. Okay, what else? Let's get rid of these two. I'll show you something. If you go to the node_modules directory, and then you find webpack.mix.js, this is an example mix.js file. And at the very bottom, you'll get a quick glance at the full API you can use here. And you can review anything you may not know about. For example, if you never want OS notifications, you can just call mix.disableNotifications. Let's talk about the first things like mix.less and stylus. So in older versions of mix, or even Laravel Elixir before that, it was always awkward because we would just include the dependency for less, even if you never use mix.less. But now we take any dependencies like this, and we load them on demand. So for example, let's imagine we

because we would just include the dependency for less, even if you never use mix.less. But now we take any dependencies like this, and we load them on demand. So for example, let's imagine we switch this over to mix.less, because that's your preference, like so. And I'll create that, assets/less/app.less. Okay, so now you want less compilation. So if we compile this down, it'll pick up on the fact that you need additional dependencies. So this one time alone, it will pull those in. Once it has it, it will continue your compile. So now you are successfully working with less compilation. What else? Let's go back to our API here. One thing would be mix.babel. Let's talk about that one. So I'm going to bring this back to what we had a little earlier, where we combined some files. But let's imagine that 1.js is an ECMAScript class like this. Okay, well, yes, if we try to compile that down, that all works just fine.

we had a little earlier, where we combined some files. But let's imagine that 1.js is an ECMAScript class like this. Okay, well, yes, if we try to compile that down, that all works just fine. And if we take a look at vendors.js, yes, it includes it there. But if we try to change it to yarn run production, and it needs to apply uglification, well, right now you'll see an error here, unexpected token. But look at the top. Whoops, we had trouble minifying this file. Perhaps you need to use mix.babel instead. So the issue is you have ECMAScript 2015 code that the current version of our Uglify plugin cannot support. So instead, we're just going to switch this over to Babel. And that's going to do the same thing, but it will also add a layer of Babel compilation before. So if we give that another run, you'll see that this will compile properly. Okay, so what else? Another important change with Mix 1.0 is how versioning is applied.

before. So if we give that another run, you'll see that this will compile properly. Okay, so what else? Another important change with Mix 1.0 is how versioning is applied. So let's just do JavaScript compilation, yarn run dev. And you'll see that in previous versions of Mix, when you apply .version, it will use file-based versioning. So you would get app. and then some long hash .js. But now, with Mix 1.0, that's all applied in the query string here. And this not only makes the Mix codebase a lot simpler and easier to track and to monitor files for changes and to delete old version files, it all got a little tricky here. But now, by keeping it within the Mix manifest file, whenever you use the mix function in your Laravel projects, you'll automatically get a query string that's equal to basically the MD5 of the file you're compiling. So for example, if we pull up npm run watch, and let's do this. Let's put that

you'll automatically get a query string that's equal to basically the MD5 of the file you're compiling. So for example, if we pull up npm run watch, and let's do this. Let's put that over here so you can see how this works in real time. Okay, so we're going to change this. And as I compile this, you're going to see that the hash changes. So one more time, compile, and then over here, that will automatically update to reflect the change. So this means any time your main JavaScript file changes will bust the cache, and then when you push it to production, it will pick up on that. And by the way, make sure if you're using anything like Cloudflare, just make sure you turn on the option to support query string-based cache busting. Now though, how does that affect, let's close this out, how does that affect versioning other files? So maybe I want to copy a file. So let's do this. Copy, once again, public/js/app.js to

Now though, how does that affect, let's close this out, how does that affect versioning other files? So maybe I want to copy a file. So let's do this. Copy, once again, public/js/app.js to public somewhere, one more time. Now you'll see that we will pick up on any of these files here, and we'll automatically version those as well, and they will be inserted into your mix.manifest file, and this did not happen before. So there's that, mix.manifest, and now that's represented here. So now you don't have to be responsible for manually versioning any of these files like you had to before. And this will also be true, once again, for combine. So public somewhere, one.js, public somewhere, app.js, and let's save that to all. Yeah, we're still going to get the same thing, where it will pick up on this file needing to be versioned, so that will be reflected right here with a unique ID there. Now though, if you do have other files that do not need to

same thing, where it will pick up on this file needing to be versioned, so that will be reflected right here with a unique ID there. Now though, if you do have other files that do not need to be manipulated, but you still want to version them, then you could either pass a string here or an array. So I could say, like, let's just, for some reason, version robots.txt. Okay, well now, if we run that, that file will be represented as well. And like I said, you can use a string or an array to specify multiple files. It doesn't matter. Now finally, I'll leave you with CSS purification. You might want to play around with that. So let's say we're compiling resources/assets/sass to the public/CSS directory. Now if we switch over to that example webpack.mix.js file, you'll see that we have a mix.options method you can call. And you can see that one of those options is to purify CSS. So what exactly does that mean? Well first, let's

webpack.mix file, you'll see that we have a mix.options method you can call. And you can see that one of those options is to purify CSS. So what exactly does that mean? Well first, let's turn it on. Purify CSS is true. Okay, so take a look at this. If we go into resources/app.css, let's just say we have two classes. one and two have a background of green. Okay, let's close these out. Now if I go to my welcome file, let's pull that in. So let's say we want css/app.css. And let's get rid of the welcome page markup like that. Okay, so we're gonna say hello world. And then we're gonna give this a class of one and two. Okay, so we compile everything down. Once again, you'll see that it had to pull in additional dependencies. No problem. We run mix again. And those dependencies are of course to perform the CSS purification. But anyways, now if we take a look at css/app.css, we see exactly what we had before. However, it actually

mix again. And those dependencies are of course to perform the CSS purification. But anyways, now if we take a look at css.app.css, we see exactly what we had before. However, it actually calculated that both of those classes should be there because it scans all of your Blade files. And it detected a one and a two class. Now if I get rid of that entirely, you'll see that if we run it this time, it'll pick up on the change. And now you only get the one class. Now I'll warn you, this can be incredibly powerful. But just make sure when you're done, don't just adopt it willy nilly. Make sure you, if you add this, have a look around your site and see if anything broke. Because maybe if you're calculating class names dynamically, that can sometimes be a little tricky. So by default, it's going to scan all of your Blade files and then also all of your view files to find any computed properties or computed classes or anything there. And if it finds the

So by default, it's going to scan all of your Blade files and then also all of your view files to find any computed properties or computed classes or anything there. And if it finds the class, well then that stays in your output. But if it never finds any occurrence, like it did with the two class, then it will be stripped from your output. So this can decrease your CSS file size significantly. But again, just make sure you have a look around your website and make sure nothing funny happens there. And we can talk about that more in the comments if you would like to. Okay, so I think that'll do it for a quick overview of Laravel Mix 1.0. If you have any questions, just leave them in the comments below.