Understanding vite.config
A plugins array, a few options, that's it.
What goes in vite.config.ts, the plugin model that does most of the work, and the three options every real project ends up setting.
The minimum viable config.
A Vite project with one framework plugin runs end-to-end with five lines: import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
export default defineConfig({
plugins: [react()],
}); That's a full dev server with HMR plus a production-grade build. Most of Vite's job is hidden behind the plugin; the plugin makes Vite aware of JSX, TypeScript, React Fast Refresh.
The three options you'll add.
resolve.alias: { "@": path.resolve(__dirname, "src") } lets you write import { foo } from "@/lib/foo" instead of long relative paths. server.port and server.proxy: override the default 5173 and configure proxy rules for API calls during dev. build.outDir: change dist to whatever your deployment expects.
The plugin model.
Vite plugins are Rollup plugins with a few Vite-specific hooks added. A plugin is a function returning an object with hooks like transform (modify file content), resolveId (intercept module resolution), load (return module content). The ecosystem is thousands of plugins for everything from SVG-as-component to image optimization to env-variable injection. Pick from awesome-vite; for niche needs, write your own (the API is roughly 100 lines of documentation).
A worked config.
A typical React project: import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import path from "path";
export default defineConfig({
plugins: [react()],
resolve: { alias: { "@": path.resolve(__dirname, "src") } },
server: {
port: 3000,
proxy: { "/api": "http://localhost:8000" },
},
build: { sourcemap: true },
}); React JSX support, @ alias for src, dev server on port 3000 with API proxy, production builds emit source maps. About ten lines of config; everything else is Vite's default.
Real project config
plugin + alias + proxy + source maps
The four things every project actually needs.
~10 lines vite.config.ts
= Production-ready setup
SSR is a different mode.
Vite supports server-side rendering via ssr options. For SSR-heavy projects, frameworks built on Vite (Nuxt, SvelteKit, Astro, Remix) handle the SSR config for you. Hand-rolled SSR is possible but rarely worth the effort; pick a framework that's designed for it.
Performance tuning that matters.
build.target: set to "esnext" if you're shipping to evergreen browsers — drops the transpilation cost for modern syntax. build.chunkSizeWarningLimit: bumped from default 500 KB if you genuinely need larger chunks (rare; usually a sign of missing code-splitting). optimizeDeps.exclude: list packages Vite shouldn't pre-bundle for dev — useful for libraries that conflict with Vite's bundling heuristics. Most projects never need any of these.