Article Directory
1. Why configure environment variables?
In the front-end development process of a product , generally speaking, it will go through local development, test scripts, development self-test, test environment, and pre-launch environment before it can be officially released. Corresponding to each environment may be different, such as user access to resource permissions, server address, interface address, etc. When switching between environments, different configuration parameters are required, so environment variables and patterns can be used to facilitate our management.
2. Configure environment variables in Vite
1. Environment variables and patterns
Because the project is created using VIte, we need to check the environment variables and modes in Vite before configuring the environment variables, the official website address
2. Environment variables
Vite exposes environment variables on a special
import.meta.envobject. Here are some built-in variables that can be used in all cases:
import.meta.env.MODE: {string} The mode the application runs in .
import.meta.env.BASE_URL: {string} The base URL when deploying the application. It is determined by the base configuration item .
import.meta.env.PROD: {boolean} Whether the application is running in the production environment.
import.meta.env.DEV: {boolean} Whether the application is running in the development environment (always theimport.meta.env.PRODopposite).
import.meta.env.SSR: {boolean} Whether the application is running on the server .
3. Production environment replacement
In production, these environment variables are statically replaced at build time , so use fully static strings when referencing them. Dynamic keys will not take effect. For example, dynamic key values
import.meta.env[key]are invalid.
4. env Documentation
Create these two files in the root directory
.env.dev file
NODE_ENV = dev VITE_NAME="LJY"
.env.pro file
NODE_ENV = pro VITE_NAME="LJY"
Vite uses dotenv to load additional environment variables from the following files in your environment directory :
Environment loading priority
A file for specifying patterns (for example
.env.production) will take precedence over generic forms (for example.env).In addition, the environment variables that already exist when Vite is executed have the highest priority and will not be
.envoverwritten by class files. For example when runningVITE_SOME_KEY=123 vite build.
.envThe class files will be loaded at the beginning of Vite startup, and the changes will take effect after restarting the server.
Loaded environment variables are also import.meta.env exposed to client source code as strings.
To prevent accidentally leaking some environment variables to the client, only variables prefixed VITE_ with will be exposed to vite-processed code. For example, the following environment variables:
VITE_SOME_KEY=123
DB_PASSWORD=foobar
Only VITE_SOME_KEY it will be exposed as import.meta.env.VITE_SOME_KEY source code provided to the client, but DB_PASSWORD not.
console.log(import.meta.env.VITE_SOME_KEY) // 123
console.log(import.meta.env.DB_PASSWORD) // undefined
If you want to customize the prefix of env variables, see envPrefix .
Safety Precautions
If you want to customize the prefix of env variables, see envPrefix option.
.env.*.localFiles should be local and can contain sensitive variables. You should.localadd to yours.gitignoreto avoid them being checked in by git.Since any variable exposed to the Vite source code will eventually appear in the client package,
VITE_*the variable should not contain any sensitive information.