For years, we have relied upon Mix to manage and bundle our assets for our Laravel applications. And Mix is, of course, built on Webpack. Now, Webpack technically has nothing wrong with it. It has revolutionized the way that we develop web applications. But it was also designed for a time when Internet Explorer was still something that we had to worry about. And now we live in a world where modern browsers have built-in ES module support. So you can keep using Mix if you want, or you can use Vite, which is actually the preferred way of managing our dependencies. Vite is French for fast, and it is fast.

way of managing our dependencies. Vite is French for fast, and it is fast. It has native ES module support, and it is fully integrated with Laravel. In fact, it doesn't matter how you create your Laravel project. You can choose the no starter kit. You could use Laravel Breeze or Laravel Jetstream. Vite is going to be included by default. Now, of course, Vite relies upon NPM, and chances are you have NPM. But if not, you will need to go to nodejs.org, and you will need to download the LTS version of Node.

But if not, you will need to go to nodejs.org, and you will need to download the LTS version of Node. The version itself doesn't matter. We install Node just so that we can get access to NPM. So download Node, take the defaults, it's a very straightforward installation. And then when you have NPM, you are ready to start using Vite. Now if you created your project using the non-starter kit, then you will need to run npm install. If you used the Breeze or the Jetstream starter kits, then the npm install is part of that installation process.

If you used the Breeze or the Jetstream starter kits, then the NPM install is part of that installation process. You won't have to do that. Now, before we do anything, let's take a look at the vite.config.js. It is at the root of our project, and it is a very simple configuration. Now, of course, more complex projects will have a more complex config. But at least to get started, it's very straightforward. So the whole magic behind the Laravel and Vite integration is this Laravel Vite plugin. We can see that it is being configured here with two properties.

So the whole magic behind the Laravel and Vite integration is this Laravel Vite plugin. We can see that it is being configured here with two properties. The first is input. The second is refresh. Now the input property contains all of the files that are essentially our entry points. And while there are only two listed here, we can have as many entry points as we want. So for a single page application, we would typically have just one entry point, which would be our JavaScript. And then inside of that app.js, we would import everything else. But if you're developing a typical web application where you want to sprinkle in your own JavaScript,

And then inside of that app.js, we would import everything else. But if you're developing a typical web application where you want to sprinkle in your own JavaScript, well, you could still use Vite because you could have as many entry points as you need. So if you need different JavaScript files for different pages, then you can do that. You just need to set up those entry points. So just to continue down that path, if you need an app.js, but you also need JavaScript specifically for the welcome view, you can have a welcome.js or whatever you wanted to call it. We're going to keep things simple and just have the two entry points, the CSS and the JavaScript. So right now there's nothing inside of app.css. But if we take a look at app.js, we can see that it is importing Bootstrap, which this

So right now there's nothing inside of app.css. But if we take a look at app.js, we can see that it is importing Bootstrap, which this is not the Bootstrap CSS framework. This is just a JavaScript file that is setting up Axios, making it globally accessible, and then setting up the headers. So nothing really going on there. But let's do this. Let's open up our welcome.blade.php. And it currently does not use any of our assets being bundled by Vite. But we can easily change that.

And it currently does not use any of our assets being bundled by Vite. But we can easily change that. We can use the Vite directive. And then let's say we want to pull in our app.js file. So we will simply pass in the path of that asset, and it's going to load that in the page. However, before we do that, we need to start up the Vite development server, because this whole integration relies upon two things. It relies upon our Laravel application, and it also relies upon our Vite development server. In fact, whenever we run the dev script, we will see two URLs. If we click on this first one, that's localhost:5173, that takes us to this page, where

In fact, whenever we run the dev script, we will see two URLs. If we click on this first one, that's localhost:5173, that takes us to this page, where we see that this is the Vite development server that provides hot module replacement. To access your Laravel application, you will need to run a local development server. And then it tells you how to do that. I'm using Hurd, so I want to go to laravelvite.test. And if we open that up, then we will see our good old welcome view. Right now, there's nothing happening as far as JavaScript, but it is loaded. And if we go to our code, let's open up app.js, and let's add an alert. Let's say alert('hello Vite').

And if we go to our code, let's open up app.js, and let's add an alert. Let's say hello Vite. And whenever we save this and go back to the browser, we see that it automatically refreshed. There is our alert box. And this is one of the wonderful things about this integration between our Laravel project and Vite. Just about any change that we make to any of our assets, our views, our view components, even our routes, is going to cause the browser to automatically refresh. So not only is Vite fast as far as bundling all of our stuff together, but it's also going to speed up our development because we don't have to manually refresh anything.

So not only is Vite fast as far as bundling all of our stuff together, but it's also going to speed up our development because we don't have to manually refresh anything. It's just going to do it automatically for us. And that is controlled by this refresh property in our config. It is set to true. We can, of course, set that to false, but why would we want to do that? We want to keep that as true. And we can also change the files that it is watching. So if we wanted to watch something, I don't know, it watches a lot by default. But I guess if we wanted to watch one of our models, we could add that path to our

So if we wanted to watch something, I don't know, it watches a lot by default. But I guess if we wanted to watch one of our models, we could add that path to our config. But let's not do that. Let's just stick with the default because for the most part, the default is going to be just fine. Well, let's go back to the welcome view and let's get rid of, well, practically everything. Everything in the head, let's get rid of the class on the body. Let's get rid of everything inside of the body. And I want to add our CSS.

Let's get rid of everything inside of the body. And I want to add our CSS. So we can use the vt directive again to pull in our app.css file. And that's going to be fine. We can go back to the browser and we'll see, well, we need to get rid of that hello message. But we can see that now there's nothing inside of the body. So let's comment out that alert box so that that doesn't keep popping up. And we want to add some CSS. So let's do that by going to our app.css. Let's add a background color of navy.

So let's do that by going to our app.css. Let's add a background color of navy. And of course, whenever we save that, the browser refreshes and we see those changes. But let's look at the source here. So we see a script type module and the source is the vt-client. So whenever we use the vt directive, it is going to insert this vt-client. This client is part of that plugin. It's making the magic happen between our Laravel project and our vt project. And after we see our vt-client, we then see another JavaScript type module and there is our app.js.

And after we see our vt client, we then see another JavaScript type module and there is our app.js. If we scroll on over, we will once again see the vt client being included, followed by our JavaScript. So every time we use the vt directive, it is going to insert the vt client. Now there shouldn't be any conflict between multiple vt clients because after all, whenever we add our resources, we typically want to use the vt directive. However, in this particular case, we could do this with one statement. All we would need to do is pass an array to the vt directive and then each element in that array would be the path of the asset that we wanted to include.

All we would need to do is pass an array to the vt directive and then each element in that array would be the path of the asset that we wanted to include. And that's going to essentially give us the same result, except that now only one vt client is inserted into the page. So if we take a look at this again, we have our vt client, followed by our app.js, followed by our stylesheet. Now there are some cases where we might not want to use the vt directive and instead we would want to essentially write the raw content out. So let's say that we use the vt directive to output our CSS, but later on in the body, we want to directly output the contents of our app.js.

So let's say that we use the vt directive to output our CSS, but later on in the body, we want to directly output the contents of our app.js. We can do that not with the vt directive, but with the vt facade. We have a content method that then we could specify the path of the resource that we wanted to output. So we could have resources/js/app.js. And whenever we save that, well, we get an error. The vt manifest not found. And then it tells us where it's trying to find that. We can see that it is looking inside of the public folder and there should be a build

And then it tells us where it's trying to find that. We can see that it is looking inside of the public folder and there should be a build folder and then the manifest.json. But also notice that it says run npm run dev in your terminal and refresh the page. Well, we are running the dev script. It's running right here. But if we go back to our code and we take a look at the public folder, we'll see that there is no build folder and definitely no manifest file inside of the build folder. So what we need to do in that particular case is stop our npm script, run the build script that is going to build our assets into the public folder as we can see there.

So what we need to do in that particular case is stop our npm script, run the build script that is going to build our assets into the public folder as we can see there. Then we can run the dev script again and we could see the browser automatically refresh there. But the problem here is that we are pulling in production code because whenever we run the build script, that is essentially building our code for production. So by including the content using the Vite content method, we are pulling in production code, not development code. So this has its uses, just not for development. So getting started with Vite is very straightforward.

So this has its uses, just not for development. So getting started with Vite is very straightforward. In the next episode, we will look at how to handle static assets.