Deployment & Configuring Vite

[00:00:00]
>> Now that we have the tools that want to help us make sure that the code we are pushing to the interwebs is not broken at least help us as much as they can with making sure it's not broken. We might be ready to blast off and deploy some code for all of the Internet to enjoy.

[00:00:22]
So Houston, mission control. I believe at this point, we've linted, we've auto-formatted, we've worn our NASA-themed T-shirt, [LAUGH] and we are ready for blast-off. So let us just take a quick moment to review for the, again, those of us that are kind of new to a lot of the lingo here which again, is completely arbitrary and sort of cultural.

[00:00:54]
When we talk about deploying to production versus sometimes we deploy to development servers. But in general, we run our development server locally, but we have production out in the real world. There's probably a good reason why we use the word production, but I don't honestly know what it is.

[00:01:15]
So if anybody knows, fun fact, put it in the thing. [LAUGH] But the idea here is that we have very different use cases for these two environments. In the dev environment, we know that the user is us, the call is coming from inside the house, if you will.

[00:01:36]
And the idea is that we're trying to iterate on our code base as quickly as possible. We're trying to make those changes because I got somebody over here being like, the side is down, help, this sort of panic moment when we're running as fast as possible. We're moving fast and possibly breaking things, and we want to kind of be making choices in the way that we're running this local server that reflect that.

[00:02:04]
For example, we may wanna be assuming that we are running a very modern browser so that we don't have to go through all of the steps of transpiling or chain rewriting the syntax of JavaScript to support older browsers, for example. But in the production environment, I, the developer, I'm not the audience, the end user of this website is the audience.

[00:02:29]
And so our focus is not to get something that reloads as fast as possible and uses all the fresh hotness to make me as fast of a bug fixer as possible. But rather to make sure that we are delivering a solid, robust, working [LAUGH] ideally site to actual users in the world.

[00:02:55]
And so that's where, yeah, in Vite, we have a few different kind of default Faults here. For example, in the dev server, we again, target those newest browsers. Because we kinda assume that if we're web devs working with modern tools, we have updated our browser in less than 10 years, let's say [LAUGH] ago.

[00:03:13]
And yeah, we're watching for those changes, we're automatically reloading whenever one module changes, we're kinda putting it in. But in the production build as we saw earlier, the settings are different. We might be targeting older browsers because we want to also support users who are not JavaScript developers.

[00:03:37]
And not have other things going on in their lives and downloading the hottest freshest browser to ever come off the assembly line. Anyway, the preview server that we used earlier that goes along with the NPM run build, once we run that, nothing is served. We can run NPM run preview to serve up all of those files that were built in dist.

[00:04:05]
And again, those commands came out of the box with our Vite starter package or create Vite package, and it's not gonna update, right? This is to make sure that you can test out sort of quality control your built site, not that you can be quickly editing, and then quickly seeing the new change, and quickly editing again.

[00:04:26]
So very different focus. And this is all to say, there's different settings for what happens in these environments. And so sometimes that also involves having different environment variables. For example, maybe you have an API token, something like that. This is out of the scope of this course, but you might have certain data secrets that you don't want to commit to GitHub in your local environment that are different from the ones that your production site would be using.

[00:04:58]
So maybe you've got your own personal dev token for GitHub, but your company has a different one that they use when they're accessing the GitHub API for your fancy open-source helper website, I don't know. The point being the two environments have their very different needs and very different aims, and so we have to be conscious of whether we're in one or the other.

[00:05:27]
And Vite is already conscious of that with those defaults. But we can also configure Vite to tell it what we want it to do. So we can customize all kinds of different options around Vite, including, for example, where we're intending to host this site. For example, is this gonna be at anjana.dev?

[00:05:52]
That's it. Or is it gonna be @anjana.dev/selfie-cam? Or is it gonna be @projects.anjana.dev/selfie-cam? What's gonna happen here? And we can also tell it things like how the build should work. For example, which browsers do I wanna target? Do I know that some of my users are on even older browsers than the default in Vite?

[00:06:18]
I can configure that. And there's all kinds of other settings, we're not gonna go into it all. There's a whole Vite course you can take that I'm sure covers a whole bunch of other tips and tricks. But suffice it to say that we can create a vite.config.js file.

[00:06:38]
And it seems that at the moment, there is starting to be a little more consensus around a lot of projects use this projectname.config.js now. And perhaps we will see more of those .config.js files. But in any case, that's Vite 1, it's just dictated if you have a v.config.js file and it conforms to the way Vite conflg should be created, basically, what a Vite config is.

[00:07:11]
And similar to our ES lint configs and all these other things is essentially a JSON file, or in this case, a JavaScript object that has keys and values, and keys and values that override any defaults that we might want to do. So, for example, there's a there's a base option where I can tell it where this site is going to be, what the base path is, so essentially, where that kinda slash starts.

[00:07:40]
And then things like, I want the server to run on a different port, or I want the build to target different browsers and things like that. Now, we're not gonna worry about all of the different config options, you can read all about them on the Vite docs. But if we wanna deploy a project site, we're probably gonna have some kind of slash project name in our URL.

[00:08:05]
So, that probably is one that we're gonna wanna set is this base URL for our site. And what that looks like is gonna depend on where we're hosting our site. So there's a whole bunch of different places, the different services and companies essentially that offer really convenient platforms for deploying your sites and hosting them even up there.

[00:08:35]
And then it will integrate with your GitHub account and just sort of automagically update your website, if you have the right config settings, whenever you push to your GitHub repository. There's a whole bunch of options, and we're not gonna really go into them. But for example, Netlify and Vercel are a couple that you might see out there.

[00:08:56]
For example, somebody might share a demo project and it's myselficam.netlify.com or something like that, right? So these are a couple of popular ones. But since we are already using GitHub, we can also use GitHub's built-in solution for this, which is called GitHub Pages. So this is a whole whole thing.

[00:09:19]
And there's all kinds of settings, and whatever, and configuration, and everything, you can read all about it. But essentially, when we have a Git repository, and I believe if we're on the free plan, it has to be a public repository. But when we have one, we can also deploy a static site here to GitHub pages, essentially by just tweaking some settings.