How to Set Up a Vite Config Without Guessing

Vite works with almost no configuration, which is a genuine strength and the reason most projects’ config files are a copy of someone else’s. Then you need a path alias, or a dev proxy, and the copied file has neither — or worse, has the alias in one place and not the other.

Three things account for most of what a real project’s config actually needs.

Path aliases, and the two-places problem

An alias turns import { thing } from '../../../lib/thing' into import { thing } from '@/lib/thing'. Worth having on any project deeper than two folders.

The catch is that two separate systems need to know about it.

Vite resolves the alias at build time, from resolve.alias in the config. Get this wrong and the build fails loudly, which is at least clear.

TypeScript resolves it at type-check time, from paths in tsconfig.json. Get this wrong and the build succeeds while your editor shows red squiggles on every aliased import and offers no autocomplete.

The second failure is the annoying one, because everything works and the tooling is quietly broken. Both files need the same mapping, and keeping them in sync is a manual job unless you use a plugin that reads tsconfig directly.

The dev proxy

In development, the frontend runs on one port and the API on another. A browser treats those as different origins, so requests are subject to CORS.

You can loosen CORS on the API for development, and that’s the option that occasionally gets left enabled in production. The better approach is a dev server proxy: requests to /api are forwarded by Vite to the API server, so from the browser’s perspective everything is same-origin.

changeOrigin: true is worth knowing about — it rewrites the Host header to match the target, which matters when the API validates it or when you’re proxying to an external service.

Build target

The build target decides how much your output gets transpiled and which syntax survives. A modern target produces smaller, faster output and drops support for older browsers. A conservative target does the reverse.

The default suits most applications. Change it deliberately, based on the browsers you actually need to support rather than a general instinct toward compatibility.

Common mistakes to avoid

• Setting the alias in Vite and forgetting tsconfig, so the build works and the editor doesn’t.
• Loosening CORS on the API for local development and shipping that config.
• Enabling production sourcemaps and serving them publicly, which exposes your original source.
• Editing the config and expecting hot reload to pick it up — config changes need a dev server restart.
• Copying a config from a project using a different framework plugin.

How to do it with Vite Config Generator

The Vite Config Generator assembles the config with the parts that projects actually need.

1. Choose the framework and what the config must handle.
2. Add path aliases — and mirror them in tsconfig.json paths.
3. Add a dev proxy if your API runs separately in development.
4. Copy the config into the project root and restart the dev server.

Vite’s own configuration reference is the authority on every option. Other developer tools are in the tools directory.

Frequently asked questions

Why do aliases need setting in two places?

Vite resolves them at build time from vite.config; TypeScript resolves them at type-check time from tsconfig paths. Both need the same mapping or your editor and your build disagree.

When do I need a dev proxy?

When the frontend and API run on different ports in development. Proxying avoids CORS locally without weakening anything in production.

Should sourcemaps be enabled in production?

For debugging, yes — but they expose your original source. Many teams generate them and upload to an error tracker rather than serving them publicly.

Final thought

If your build passes and your editor is full of red, check the alias in tsconfig. That mismatch accounts for most of the time people lose to Vite configuration.

Try the free Vite Config Generator