Why does the alias output use path.resolve(__dirname, ...) instead of a plain string?

Vite's resolve.alias matches against absolute paths, and a plain relative string can resolve inconsistently depending on the current working directory a command is run from. Wrapping the target in `path.resolve(__dirname, ...)` anchors it to the config file's own location, which is the pattern Vite's own documentation and most real-world vite.config.ts files use.

What does server.proxy actually do?

It forwards matching request paths from Vite's dev server to another origin, most commonly an API server running on a different port, so the frontend can call relative paths like /api/users during development without hitting CORS or needing an absolute backend URL baked into the code.

Does this affect my production build, or only `vite dev`?

server.proxy only applies to the Vite dev server; it has no effect on the production build or on a deployed app, which typically needs its own reverse proxy or CORS configuration on the actual hosting platform.

What if I don't need a framework plugin?

Choose "none" and the generated config omits the framework plugin import entirely, useful for a vanilla TypeScript/JS project or a library build that doesn't compile JSX/SFCs.

Vite Config Generator - vite.config.ts Builder

Overview

Introduction

A vite.config.ts usually accumulates the same handful of additions over a project's life: a framework plugin, a couple of path aliases matching tsconfig, and a dev-server proxy to a local API, each requiring slightly different syntax to get right.

This tool generates a working vite.config.ts with all three, plus basic build output options, from a simple form.

What Is Vite Config Generator?

A vite.config.ts generator covering the framework plugin (@vitejs/plugin-react, @vitejs/plugin-vue, @sveltejs/vite-plugin-svelte, or none), resolve.alias rows, server.proxy rows, and build.outDir/sourcemap options.

The output is real, valid TypeScript using Vite's `defineConfig()` helper, with only the sections you actually configured (aliases, server block) appearing in the file.

How Vite Config Generator Works

Selecting a framework adds the matching plugin's import statement and a call to it inside the `plugins` array; selecting "none" omits this entirely.

Alias rows are turned into `path.resolve(__dirname, ...)` entries under `resolve.alias`, and proxy rows become the `server.proxy` object, both sections included only when at least one row has been filled in.

When To Use Vite Config Generator

Use it when bootstrapping a new Vite project and you already know you need a path alias (like @/ pointing at src/) and/or a dev-server proxy to a local backend.

It's also useful for quickly producing the config snippet for the framework plugin swap when migrating a project between React, Vue, and Svelte tooling.

Often used alongside tsconfig.json Generator, Rollup Config Generator and Tailwind Config Generator.

Features

Advantages

Alias output uses the `path.resolve(__dirname, ...)` pattern Vite's own docs recommend, avoiding relative-path resolution surprises.
Only includes the resolve/server blocks that actually have content, keeping the generated file free of empty `alias: {}` or `proxy: {}` clutter.
Covers React, Vue, and Svelte plugin setup in one tool so switching frameworks doesn't mean researching a different plugin's import shape from scratch.

Limitations

Doesn't cover every Vite plugin ecosystem (Vite PWA, legacy browser support, SVG-as-component plugins); it focuses on the framework plugin plus alias/proxy/build basics.
server.proxy only affects the dev server; a deployed production build needs its own reverse-proxy or CORS setup, which this tool doesn't generate.

Examples

React app with a path alias and API proxy

Input

framework: react, alias: @/ -> src/, proxy: /api -> http://localhost:4000, outDir: dist

Output

import { defineConfig } from "vite";
import path from "node:path";
import react from "@vitejs/plugin-react";

export default defineConfig({
  plugins: [react()],
  resolve: {
    alias: {
      "@/": path.resolve(__dirname, "src/"),
    },
  },
  server: {
    proxy: {
      "/api": "http://localhost:4000",
    },
  },
  build: {
    outDir: "dist",
    sourcemap: false,
  },
});

Best Practices & Notes

Best Practices

Keep the alias here in sync with the same alias defined in tsconfig.json's `paths`, since Vite and TypeScript resolve module paths independently and need matching configuration.
Enable build.sourcemap in staging/debug builds so stack traces from a deployed bundle map back to original source, and consider disabling it for the final production build to reduce output size.
Prefer a proxy over hardcoding an absolute backend URL in frontend code, so the same code works against different backend URLs per environment without a rebuild.

Developer Notes

Aliases resolve through Node's `path.resolve(__dirname, ...)` rather than a bare string because Vite's alias matching operates on the resolved absolute path, and `__dirname` is available at build-config-evaluation time even under an ESM-flavored vite.config.ts since Vite processes config files with its own loader. The `server.proxy` shorthand string form (`"/api": "http://localhost:4000"`) is used here rather than the object form with `changeOrigin`, since the vast majority of local dev proxy setups just need the target URL.

Vite Config Generator Use Cases

Bootstrapping vite.config.ts for a new React, Vue, or Svelte project
Adding a dev-server proxy so frontend code can call a local backend API without CORS issues
Setting up a path alias matching an existing tsconfig.json paths entry

Common Mistakes

Defining an alias in vite.config.ts but forgetting to add the matching entry to tsconfig.json's `paths`, so the editor's type-checker can't resolve imports even though the build works.
Assuming server.proxy configuration also applies to the production build, when it only affects the Vite dev server.

Tips

Use the tsconfig Generator to add a matching `paths` alias entry alongside any alias you define here.

Vite Config Generator