npm run dev # development server - fast refresh, unminified, helpful error overlays
npm run build # production build - minified, optimized, outputs to dist/The development server (used throughout this entire course) prioritizes fast feedback and helpful debugging tools. A production build strips out development-only warnings, minifies your code to a fraction of its original size, and optimizes it for real users' actual load times — the two modes are deliberately very different.
# .env.development
VITE_API_URL=http://localhost:3001
# .env.production
VITE_API_URL=https://api.myapp.com// In your code:
const API_URL = import.meta.env.VITE_API_URL;
fetch(`${API_URL}/users`);Chapter 21's fetch("/api/users") calls need to point somewhere different in development versus production. Environment variables (note the required VITE_ prefix in Vite projects) let the same code automatically use the right URL in each environment, without hardcoding it or manually editing files before each deploy.
Vite automatically handles significant optimization during npm run build: minification (removing whitespace and shortening variable names), tree-shaking (removing code you imported but never actually use), and code-splitting your lazy()-loaded chunks from Chapter 31 into separate files. To see exactly what's taking up space in your final bundle:
npm install --save-dev rollup-plugin-visualizerTools like this generate a visual treemap of your final bundle, making it easy to spot an accidentally included huge library or duplicate dependency that's bloating your app's download size.
Since production code is minified into unreadable single-letter variable names, source maps are separate files that map that minified code back to your original, readable source — letting error-tracking tools (and your own browser DevTools, if enabled) show you the real file and line number when a production error occurs, rather than an unreadable minified stack trace.
Writing fetch("http://localhost:3001/users") directly works fine in development, but breaks completely the moment you deploy to production, where that localhost address doesn't exist. Always use environment variables for anything that differs between environments — API URLs being the most common example.
Set up a .env file with a variable for an API base URL, and reference it in a fetch call using import.meta.env.
// .env
VITE_API_URL=https://jsonplaceholder.typicode.com
// App.jsx
function App() {
const API_URL = import.meta.env.VITE_API_URL;
useEffect(() => {
fetch(`${API_URL}/users`)
.then(res => res.json())
.then(console.log);
}, []);
return <p>Check the console for fetched data.</p>;
}Q Why do Vite environment variables need a VITE_ prefix?
This is a deliberate security measure — Vite only exposes environment variables prefixed with VITE_ to your client-side code, preventing you from accidentally bundling sensitive server-only secrets (like database passwords) into code that ships to every visitor's browser.
Q Should .env files be committed to Git?
Generally, no — .env files often contain values that differ per developer or environment (and sometimes secrets), so they're typically added to .gitignore. A .env.example file with placeholder values is usually committed instead, documenting what variables are needed.