npm run dev, there we go. It compiled right here. And if we take a look at public/css/app.css, sure enough, we get our compiled code. Now, once again, remember, you should run npm run watch if you need to keep an eye on changes. And of course, when you're working on your CSS, this is something you very much need. If you had to rerun this command every single time you made a change, it would be horrible. But anyways, let's switch over. We'll change that primary color to brown. If we view the compiled file now, it automatically reflects the change. Now, in addition to core Sass compilation, we also run your CSS through some post-CSS plugins. And one that we activate out of the box is basic auto-prefixer support. Now, every year that we move forward, this becomes a smaller issue. But especially in the early days of CSS, if you wanted to have any support whatsoever, you needed to apply vendor prefixes to all of the CSS3 properties.

and then update that. Okay. So, now let's look at that file again. And sure enough, this is what we get. Same thing. But yeah, like I said with stylus, if you don't like semicolons, get rid of them. If you don't like the braces, yeah, get rid of them. So, you could do this if you like as well. Save it. Switch over. Still get the same thing. You could even get rid of, believe it or not, the colons as well. So, some people even do this. This could be a bit much, in my opinion. But actually, it's fine. It's up to you. So, once again, let's do brown to prove that it does update. And if we switch over, now you get that. So, using stylus is incredibly flexible in that regard. Now, if I switch back to my webpack.mix file, there will be situations where you want to compile two different root CSS files, right, or a stylus file or sass. In those cases, you're just going to make a second call. So, we could do mix.stylus and then run it.

where you want to compile two different root CSS files, right, or a Stylus file or Sass. In those cases, you're just going to make a second call. So, we could do mix.stylus and then run it again. Or it's a fluent API. So, I could also just say mix.stylus.stylus. So, maybe here you have like a backend file that you want to compile separately. This is how you would do that. So, let's set that up. Stylus backend.style. And then we'll just have backend. background is black because we're edgy and everything needs to be black. So, close that out. Now, I'm going to rerun this to reflect the change. And you'll now see we have two compiled files. One for your main app styles and then, of course, one for your backend CSS. Now, back in my webpack.mix file, there's one more thing I want to show you. So, yes, we can use mix.sass. And I would say most people will probably reach for this. However, it's important to understand that when you run

there's one more thing I want to show you. So, yes, we can use mix.sass. And I would say most people will probably reach for this. However, it's important to understand that when you run these commands, they are being filtered through webpack. And a number of things actually take place. And as it turns out, this is some of webpack's real power is that it has the ability to parse your CSS and modify it or tweak it or change it or update it. So, for example, one thing webpack provides is if you reference a relative image, well, we will detect that. We will automatically move it to your public directory and then it will rewrite the URL within your compiled CSS file. Let me show you that. Let's switch back to a sass file. So, we could do app.scss or you can do that app.sass syntax as well if you prefer that. Anyways, let's take one more second and do a final rename here. And rename that file to app.scss. Anyways, you'll also see that I have

app.sass syntax as well if you prefer that. Anyways, let's take one more second and do a final rename here. And rename that file to app.scss. Anyways, you'll also see that I have this images directory. So, maybe I want the background of my website to be a link to this caret that you see here. So, if we want to reference that locally, well, we could say go to the assets directory, into images, and then grab caret.jpg. And we definitely need to ensure that this repeats. So, that will happen automatically. But just to be redundant, we will add that. Okay. So, I'm going to give this another run. And I want you to see what happens here. You'll see that we have this new file here. So, what exactly is going on there? All right. Well, let's take a look. If we go to our compiled file, you'll notice that the URL is different from what we had here. And this is happening because of Webpack. So, Webpack encountered this relative URL.

look. If we go to our compiled file, you'll notice that the URL is different from what we had here. And this is happening because of Webpack. So, Webpack encountered this relative URL. But you got to remember, you're compiling that down to your public directory. So, if Webpack didn't do anything, well, you then have a relative URL that may not be correct anymore. And so, it all depends upon how you've written your style sheet. For example, you might have written this with the understanding that, okay, it's going to compile down to my public directory. So, from there, I want this relative path. Or this relative path could be from your resources/assets directory. You see how it is? So, the way Webpack works is, it's always going to assume this relative path is relative to where the current uncompiled file is. So, it found this image and it decided, okay, well, you're moving it to the public directory. So, I'm going to grab that image,

path is relative to where the current uncompiled file is. So, it found this image and it decided, okay, well, you're moving it to the public directory. So, I'm going to grab that image, move that over as well. You'll now see this file here. And then we're going to rewrite your CSS file to point to that new location. And it also adds a query string here for cache busting purposes. Anyways, that's how that works. Now, nonetheless, though, this can sometimes trip people up because maybe that relative path you had, you had already taken under consideration and you knew that that path would be assuming the public directory. Or maybe you just don't want Webpack to touch it at all. Fair enough. You have a couple choices in those cases. One, you can specify a set of options. So, I could say processCssUrls is false. So, with Laravel Mix, as you can imagine, there's many different settings, many different options that we will

you can specify a set of options. So, I could say processCssUrls is false. So, with Laravel Mix, as you can imagine, there's many different settings, many different options that we will assume by default. And if you ever need to tweak those or change them or modify them in some regard, often you can reach for mix.options. So, in this case, the property we care about is processCssUrls. Do we want Webpack to look at those URLs and tweak them and move images around or move assets and then update your paths? If you don't want that, set processCssUrls to false. So, now I'm going to give it another run and you'll see, yep, there's no more reference to that image. And, in fact, the compiled CSS file will be identical to what you typed in. Just keep this in mind. Now, alternatively, you may not want your Sass compilation to touch Webpack. You might be thinking, well, I have everything ready to go. I don't need Webpack to do any magic.