Oftentimes, it's useful to have some variables set to different values, depending on the environment your project is running in. For example, you might use an API key for a test account in your headless CMS during development, but use a different API key in production. That way, you don't accidentally alter production data while you're developing. This is where environment variables come in.
Environment variables in V. env object. With the development server running, let's console log that and see what it looks like by default. Nice!
So we've got an object with some default environment variables automatically provided by V. First is the base URL the app is being served from. This is configurable via the base option in the V config file. and can be changed at the root of your app isn't the same as the root of your server.
Dev means we're running in development mode. Likewise, prod faults also means that we're running in development mode. And both of these would be reversed if we were running the preview server instead of the dev server. Lastly, mode gives us a string version of the environment we're operating in.
When running the dev server, this will always be development. After running the build, This defaults to production, but can also be changed to values like stage, staging, test, or really anything you'd like. This is possible by passing the mode flag to the build command. Notice the output in the terminal now reads building for staging.
Sweet! These built-in environment variables can be very useful, but we can also define our own environment variables. env file. So let's create one.
env file, we can define our variable names in all caps by convention, and then set them equal to whatever value we'd like. And on each new line, we can provide different variables. If I save the file and look back at the console log in the browser, you'll see that our new environment variables aren't included. This might be a little surprising at first.
But this is actually a feature of Vite to help us from accidentally exposing sensitive values to the client. So if you have any environment variables that can be exposed to the client, you must prefix said variable with Vite underscore. And I'll just do it for both of these. Great.
Now they both show up in the console. Now if we were to build for production, These variables would be statically replaced in the final bundle. Let's see what that looks like. I'll run npm run build and then in the resulting disk directory under assets and then this index dot some kind of crazy hash dot js If I search for one of the variables Yeah, you can see where the value has been inserted as a static value While we're here You can also see that mode is production.
Let's run the build command once more with the mode flag set to staging, just so you can see that change in the generated file as well. I'll click up in my terminal a few times to get back to the command we ran a few moments ago where the mode was set to staging. Then I'll open the newly generated JavaScript file and search for mode real quick. Nice.
This time it says staging. All right. env file is not the only place that you can register these environment variables. mode.
These can be very useful, depending on if you want the values to be stored in your Git repo or not, and in which mode, like development, production, staging, and so on, that you want the values to be stored for. So, read the docs for more info on these if you'd like to use them. Lastly, these variables could even be defined somewhere in your host's admin dashboard, depending on your host. For instance, Netlify provides an interface for storing environment variables like this.
Just remember, those values will be statically inserted at build time. So, if you're wanting to set the variables directly on your host, your project will need to be built by your host as well. Oftentimes, it's useful to have some variables set to different values, depending on the environment your project is running in. For example, you might use an API key for a test account in your headless CMS during development, but use a different API key in production.
That way, you don't accidentally alter production data while you're developing. This is where environment variables come in. Environment variables in V. env object.
With the development server running, let's console log that and see what it looks like by default. Nice! So we've got an object with some default environment variables automatically provided by V. First is the base URL the app is being served from.
This is configurable via the base option in the V config file. and can be changed at the root of your app isn't the same as the root of your server. Dev means we're running in development mode. Likewise, prod faults also means that we're running in development mode.
And both of these would be reversed if we were running the preview server instead of the dev server. Lastly, mode gives us a string version of the environment we're operating in. When running the dev server, this will always be development. After running the build, This defaults to production, but can also be changed to values like stage, staging, test, or really anything you'd like.
This is possible by passing the mode flag to the build command. Notice the output in the terminal now reads building for staging. Sweet! These built-in environment variables can be very useful, but we can also define our own environment variables.
env file. So let's create one. env file, we can define our variable names in all caps by convention, and then set them equal to whatever value we'd like. And on each new line, we can provide different variables.
If I save the file and look back at the console log in the browser, you'll see that our new environment variables aren't included. This might be a little surprising at first. But this is actually a feature of Vite to help us from accidentally exposing sensitive values to the client. So if you have any environment variables that can be exposed to the client, you must prefix said variable with Vite underscore.
And I'll just do it for both of these. Great. Now they both show up in the console. Now if we were to build for production, These variables would be statically replaced in the final bundle.
Let's see what that looks like. I'll run npm run build and then in the resulting disk directory under assets and then this index dot some kind of crazy hash dot js If I search for one of the variables Yeah, you can see where the value has been inserted as a static value While we're here You can also see that mode is production. Let's run the build command once more with the mode flag set to staging, just so you can see that change in the generated file as well. I'll click up in my terminal a few times to get back to the command we ran a few moments ago where the mode was set to staging.
Then I'll open the newly generated JavaScript file and search for mode real quick. Nice. This time it says staging. All right.
env file is not the only place that you can register these environment variables. mode. These can be very useful, depending on if you want the values to be stored in your Git repo or not, and in which mode, like development, production, staging, and so on, that you want the values to be stored for. So, read the docs for more info on these if you'd like to use them.
Lastly, these variables could even be defined somewhere in your host's admin dashboard, depending on your host. For instance, Netlify provides an interface for storing environment variables like this. Just remember, those values will be statically inserted at build time. So, if you're wanting to set the variables directly on your host, your project will need to be built by your host as well.