Your Default Vite Config Is Not Enough

Most V developers I talk to don't make any changes to their V config file and that's a mistake. There are a lot of really nice options that'll make your job easier as a developer when you're testing, when you're using locally or when you're building for production. Let me show you a few of them that I like. All right, first I want to start off with this alias. This alias maps in this case this app components to this file URL, this source components. And if you look at the app view, you could see them here. So instead of putting the exact path or the relative path, you can put at components and where it's located at. Now with V8, they actually had a new option which I think everyone should try out. So instead of putting this alias, which means you really have to put it in two places. You have to define it inside the V config file that we have here and then also define it in your TS config. Otherwise, you'll get red squiggly lines everywhere. You can actually just define it in one place only. So, what I'm going to do is I'm going to add in this TS conffig paths. And what this is saying is that instead of using this alias, it's going to use the path that you set up in your TS config file instead. So, it's going to use these inside here. So, now you have just one source of truth instead of having it in multiple places. Now, if I take a look here, I'm getting an error. So if I npm rundev here and then I switch this from true from false to true and then I look at my application it is running as I expected. Of course if I put it back to false meaning it's looking for this aliases then it gives me an error and doesn't work correctly. One caveat one trade-off is it will take a little bit longer to build depending on how nested you have in your components and how complicated your paths are. But I feel like for most applications, you should try to turn this on, set the TS config path to true, and then see how well it works for you. Another must you should look at is the forward console here on line 30. Forward console is a new feature in V8 that actually will forward your errors from your console to your terminal. Let me show you how this works. So in here, I have my server running. And if I look at this forward console demo that I created, I'm just running this console warning and console error. And I have a couple of buttons associated with that. So if I look at my application, I have send console warn, send console error, and throw unhandled error. So if I bring up the console, if I just click one of these buttons, send console warn. Uh you can see here this sent was sent from the browser. Send console error. Uh so I sent two options to the console. And if I come back over to my application, my terminal, you can see they're actually also in the terminal window. So this is actually really awesome because if we're using something like AI coding assistance or something like playright or Cypress and it's doing end toend tests, typically these console warnings or console errors are just swallowed and the agent will never know about them. You can actually do a couple levels here. You could set what levels you want to see. In this case, I set warning and error. But if I want to, I have a whole bunch I can explicitly set, debug, error. You can even have just console logs show up and be sent to the terminal as well. So this is a really powerful feature. I would highly recommend everyone to try it out. Next, I want to show you this command. And by the way, this is inside the server block here. You can set a proxy. So that way when you're testing locally, you don't have to set up cores and you can test more how it will probably be in production. Let me explain that. So in this case, I created a new API server. And this API server is pretty simple. All that it's doing is it has two paths. It has a health path and a Coors health path. So we're not going to touch Coors health, but in the SLHalth path, you can see here it just returns a 200 and a message response from 8079. So it's very a very simple app, but you can see here in the /help, it doesn't have cores. And what that means is if you try to send a message from a different domain or local host from one port to the other and corors isn't set up, you're going to get corors errors. So if I look inside here and I look at my proxy demo, I'm doing a fetch here on line 20 to API health. So this is going to proxy anything s through slash API and it's going to send it to the localhost 8080 which is where my API server is running actually at the top here port 80. uh and then it's going to send information back. And then I also have a test direct where I'm just going to pass in the whole URL. So this is really nice. I don't actually have to pass the whole URL. It's already proxied in. Uh and this will work when I run it in development. And I don't have to put in this cores value. You can see here in this API server, I have cores in in this course health. So let's take a look at what this looks like. Uh, we're going to close this console and then we're going to scroll back down to our server proxy. So, I have two buttons here, via proxy API health. You can see it says 200 and direct. It doesn't work as I expect it. The reason it doesn't work is that we are hitting, if you can see here, we're hitting the exact URL, but the URL doesn't have cores set up in it. So, I highly recommend when you're dealing with multiple servers. In this case, I'm running this API server and you know that you're not going to use cores, just set up this proxy so when you're testing locally, you don't have to worry about it. Another really nice command is this HMR overlay. So, let me see if you've ever seen this happen. So, if I go back to my app view, I have this kind of hangling uh this div right here. So, if I take a look here, everything's working. But if I put this div and I uncomment it out and I accidentally leave it here, you could see here I actually have this console message in the console, but I can still see everything inside here. So this is nice because if this is it's defaulted to true normally like this, if I have this on, then I get this big ugly error. I don't know about you, I'm not I don't love this big ugly error, especially if I'm doing a lot of UI changes. it kind of just stops me in my tracks. So, this might be personal preference, but I really like to leave this overlay on false. That way, if I'm running things, I can still see it depending on obviously this air stopped the from it from showing, but I can have this on and look in the console and see the air, which I kind of prefer. Another really quick tip is you have this open. It's inside the server block here. If you set this to true, uh, anytime you stop and restart the server, it'll automatically open up a new window. And you can't see that here, but it did on my other screen here. It went ahead and opened, uh, another window. So, I kind of like when I'm quickly going through and changing things. I like to have this on uh, just because it it just opens up a new window right away and I can see the changes soon as I start the server, which is really nice. It just kind of defaults to your whatever your browser is. Another nice thing to do is to add in source maps. So, let me show you a couple different options here. So, under you can add a new build option and then under build you have a source map and you can add it hidden or inline or or you can just set it to true. So, let's set it to true first. And this will work for your production builds. So, I'm going to run npm run build and then mpm run preview. So, this is going to create a new build and then run it. So, in fact, it's actually giving me an error, which I'll delete this. I don't need this right now. So, let's run it again. And then it's completed and it's running on preview on localhost 4173. So, if I come back over here and I change the URL to 4173, here it is running. And what's nice is if I go to inspect and then I go to sources and we make this a little bit bigger, you now have this new source folder. And inside the source folder, you can see all your uncompiled view files, your utils, your components, and then you can look at all. You can now put in breaks. So in this case, I put a break right here. And if I refresh it, you can see it pauses in the debugger, and I can go in and walk through every single thing in here, which is really, really helpful. So, in this case, I'm just going to play through it so it completes it. This is really powerful when you're debugging. You want to put break points everywhere and try to figure out what's wrong. Now, if you don't want those on, uh, if, by the way, also, if you look at the disc folder, you'll have this nice maps file. This is what it creates of the source maps. If you turn this off, if we go back to source map and turn it to false and then we run the build and run the preview again, you'll see the map file disappears and you just have the JavaScript CSS files and they're they are just minified and you don't have that map file. Now, there's an in between that might be really powerful depending on what you're trying to do is instead of doing source map false, you'll do source map hidden. And what this does is if I run the build and preview again and I look at this folder, the map file is back again. However, if I go into my app and I'll refresh it here, I no longer see the source folder. It basically created the source maps, but they're not going to show up in the browser. And it's just the way it created it inside here. So be careful here. Your map file, if you set this to hidden, actually still might be deployed even though the browser might see it. someone might be able to find it anyways and download it. So, just make sure when you deploy it that you exclude all map files. That way, they don't get accidentally deployed. Anyways, why you'd want to do this is you could take this map file and there's a lot a lot of different services like Sentry that could look at this map file and help find errors in your application. So, keep that in mind. This is a really nice feature for testing and also to work with services like Sentry. One last thing I want to talk about is this environmental prefix. So by default it's set to vit but you can set it to anything you like. So in this case if I look at this environment prefix demo I added in av with just some nonsense in it API examples. I have a public API URL a public app name and then if I look at my demo it's pulling that in using import. meta.mv public API and URL. Now, you might think, does it also pull in other things like this DB password or internal API key? Well, actually, since we set the prefix to public, it won't pull in anything that isn't starting with this public underscore. So, if I come back to my app here and I refresh it, you can see here, if I come down to envixes, I have the public API URL, public app name, and then DB password, internal app API key are undefined. And just to show this works, let's imagine I change the name of this to, I don't know, public one. Let's say it's called public one. And I come back here and refresh it. And now you can see it's undefined here. And if I put it back to what it's supposed to be, now it shows up correctly. So that's a really nice thing. If you are moving from React or you're changing from Nux to a different version and they use a different prefix, then you can set it manually right here. So, those are a few things that I would definitely check out. Let me know if you make any other configuration changes in your V config below. I really appreciate it and make sure you like this video and subscribe if you want more videos like this. Thanks.