By default, Laravel's Vite plugin comes with settings that should work for the majority of applications. But there may be times when you want to modify Vite's behavior. And the Vite facade gives us many methods that we can use to do just that. So let's start off by opening up the Welcome view. And we also need to open up the vite.config.js, because what we are going to do is modify how we load our resources. We aren't going to use the Vite directive here. Instead, we are going to use the Vite facade, and we will call withEntryPoints. We pass in the same thing, an array that contains the entry points that we want to use.

Instead, we are going to use the Vite facade, and we will call withEntryPoints. We pass in the same thing, an array that contains the entry points that we want to use. So that is simply resources/js/app.js. And this is going to give us essentially the same result. Or is it? Let's make sure that I'm running the dev server. I'm not. Of course I'm not. So let's run that. Let's go back to the browser.

So let's run that. Let's go back to the browser. Let's refresh. And once everything is loaded, there we go. We have the same result. Now when the dev server is running, that means that the hot module replacement system is up and running. And we can take a look inside of the public folder. Inside of here, we see this hot file, and it just has a URL to localhost at port 5173. That is our development server.

Inside of here, we see this hot file, and it just has a URL to localhost at port 5173. That is our development server. But let's say that we don't want to store our hot file here inside of public. Maybe we want to put it inside of the storage directory. So we can do that by chaining the useHotFile method. Then we pass in the path of where we want that hot file to be stored. We can change the name of it, like I'm doing here, vt.hot. And we will also need to replicate this inside of our vt.config. So when we configure the Laravel plugin, we will add the hot file property. It needs to have the same value.

So when we configure the Laravel plugin, we will add the hot file property. It needs to have the same value. And we don't have to restart the dev server. In fact, there we go. We can see that inside of storage, we have vt.hot. And okay, that's not working. Let's do this. Let's stop this. Let's run the build script. Then let's run the dev server again, and this should start working.

Let's run the build script. Then let's run the dev server again, and this should start working. So there we go. And that's perfectly fine. And that's really good, because everything else that we are going to look at requires us to build for production. Like, for example, inside of the public directory, there's that build folder. And maybe we don't want to use build as our production folder. Maybe we want something like bundle or something like that. Well, we can just chain the useBuildDirectory method and then pass in the name of the directory that we want to use.

Well, we can just chain the use buildDirectory method and then pass in the name of the directory that we want to use. So we could use bundle in this case. Now, it is still going to be inside of the public directory. But now, instead of build, it's going to be bundle. But just like the hot file setting, we also need to replicate this inside of our vite.config. The property is buildDirectory. And once again, the value needs to be the same thing that we use in the use buildDirectory method. But with that in place, we can go back to the command line. Let's run the build script.

But with that in place, we can go back to the command line. Let's run the build script. And we will see that now our assets are being built into the public bundle directory. And the great thing is we don't have to do anything different. Everything is going to resolve the way it should be. Because we configured vt, so it should know how to do all of this stuff. So now, let's say that we want to change the name of our manifest. The default is manifest.json, but maybe we want to use something like assets.json. To do that, we call the useManifestFileName method. And then we pass in whatever name that we want our manifest file to be, so assets.json.

To do that, we call the useManifestFileName method. And then we pass in whatever name that we want our manifest file to be, so assets.json. And we need to replicate this inside of our config. But we don't do this here inside of our Laravel plugin config or even inside of the plugins. After plugins, we are going to add the build property. And it has a property called manifest, which we will simply set to assets.json. The same value, of course, that we used inside of our view. If we go back to the command line and build, we will see we are still building to the bundle directory. But now, instead of manifest.json like we got before, now we have this assets.json. The last method that we are going to look at is createAssetPathsUsing.

But now, instead of manifest.json like we got before, now we have this assets.json. The last method that we are going to look at is createAssetPathsUsing. Now, the purpose of this method is to essentially generate paths for our assets as they are loaded in the browser, not necessarily how they are stored in our project. For example, let's say that we want to store our assets on another server. Maybe we have another server that we store all of our assets for all of our applications. Well, by default, Laravel and Vite are going to look for assets locally to our project. But we want to point those references to our own CDN or something like that. So here for createAssetPathsUsing,

But we want to point those references to our own CDN or something like that. So here for createAssetPathsUsing, we pass in a closure that accepts the path of the asset and whether or not it is secure. Then we simply return the path that we want this to use. So let's say that we have a website called myAssets, but we have a subdomain for individual applications. So this application is Laravel Vite. So the path would be laravelvite.myassets.com, and then we would want to include the path of that asset. This isn't going to change how our assets are built.

and then we would want to include the path of that asset. This isn't going to change how our assets are built. In fact, we're going to see here they are still being built inside of the bundle directory. And naturally, if we take a look inside of our project itself, we still have public, we still have bundle, we still have all of those assets. But if we go to the browser, we can refresh here. We are going to see that, well, it's not going to look good. Everything, the CSS, JavaScript, everything is not going to be loaded because we can take a look at the developer tools and we will see exactly why. The browser is attempting to load resources from laravelvite.myassets.com

because we can take a look at the developer tools and we will see exactly why. The browser is attempting to load resources from laravelvite.myassets.com/ bundle/assets, and then the individual assets. So if we need to load assets from a remote location or something other than our project, then we can use the createAssetPathsUsing method. It doesn't change how our assets are built. It just changes the paths of how they are referenced in the browser. Now, I'm going to get rid of that because I want something that at least halfway works to end. So Laravel's Vite plugin gives us a lot of options for customization. We can change where the hot file is stored, the build directory, the manifest file.

So Laravel's Vite plugin gives us a lot of options for customization. We can change where the hot file is stored, the build directory, the manifest file. We can even change the paths that are used to load those assets in the browser. In most cases, I don't think you'll need to use those, but they're there if you do.