Is the generated config ready to run?

It is a valid vite.config.ts for a current Vite release, formatted the way Vite’s own docs write it. Read it before committing — the tool cannot know your monorepo layout, your router, or whether your backend really wants the prefix stripped. Everything it generates is standard, documented Vite configuration.

Why fileURLToPath instead of __dirname?

Because a config file with `import` statements is treated as an ES module, where `__dirname` does not exist. `fileURLToPath(new URL("./src", import.meta.url))` is the form that works in both an ESM config and a `type: module` package, which is why it is what the generator emits.

What does the rewrite option do?

With strip on, a request to /api/users is forwarded to /users — that is what you want when the frontend prefix is only a proxy convention. With it off, the prefix is forwarded too, which is what you want when the backend really serves /api/users. The rule table shows which of the two each line produces.

Do I need secure: false?

Only if your development backend uses a self-signed certificate. It disables certificate verification for the proxy, so the tool flags it whenever it appears in a rule — keeping it out of a shared config is the point of the warning, not a formality.

Can it check an existing config?

This page generates; a companion in the same Vite cluster checks. What it can already do here is spot the rules that most often go wrong in review: an alias that points at a package name instead of a path, a define key that is not an identifier or import.meta.env.X, a duplicate alias, and sourcemap enabled for a production build.

vite.config.ts generator

Tick the options your project needs and copy a complete, commented-where-it-matters config: aliases, dev proxy (with rewrite and WebSocket support), build target, manual chunks, env prefix. Paste your backend paths and they become server.proxy rules — including the ones that need a rewrite.

baseThe deploy path. Vite needs a leading slash; a history-mode router needs the same value.

host: true (LAN access)open the browserstrictPort

dev portpreview port

resolve.alias

define (compile-time constants)

CSS preprocessoroutDirbuild.targetchunkSizeWarningLimitmanualChunksenvPrefixoptimizeDeps.include

@vitejs/plugin-vue@vitejs/plugin-vue-jsxsourcemap (staging only)minify

This page only produces text: nothing is uploaded, and no package is installed for you — the install command is printed so you can run it yourself.

Generated vite.config.ts

import { fileURLToPath, URL } from 'node:url';
import { defineConfig } from 'vite';
import vue from '@vitejs/plugin-vue';

export default defineConfig({
  plugins: [vue()],
  resolve: {
    alias: {
      '@': fileURLToPath(new URL('./src', import.meta.url)),
    },
  },
  define: {
    __APP_VERSION__: JSON.stringify("1.0.0"),
  },
  server: {
    host: true,
    port: 5173,
    strictPort: true,
    open: true,
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/api/, ''),
      },
      '/socket': {
        target: 'ws://localhost:6001',
        changeOrigin: true,
        ws: true,
      },
    },
  },
  preview: { port: 4173 },
  build: {
    outDir: 'dist',
    target: 'es2020',
    sourcemap: false,
    chunkSizeWarningLimit: 600,
  },
  envPrefix: 'VITE_',
  optimizeDeps: { include: ['vue', 'vue-router'] },
});

Packages this config imports

npm i -D vite @vitejs/plugin-vue

Install the packages this config imports:

Notes

“ws://localhost:6001” is a ws:// target, so ws: true was added.

Why generate it instead of copying a blog post

Everyone configuring Vite for the first time ends up copying a config out of a blog post, and those snippets rot: they use `path.resolve(__dirname, …)` in an ESM-only config file, they pin a build target from three years ago, they split vendor chunks in a way that no longer matches how Vite emits shared code. The result runs, which is the problem — nobody notices the stale part until something breaks on a deploy.

So this page generates only what you tick, in a shape that matches how Vite is written today:

Only what you asked for. Leave the proxy box empty and no empty `server.proxy` object is emitted; pick no preprocessor and the config has no `css` section. A generated file should read like a file a person wrote, not like a form dump — that is also what makes it reviewable in a pull request.
The two things blog snippets get wrong. Aliases are emitted as `fileURLToPath(new URL("./src", import.meta.url))`, which works in a config that Vite loads as ESM, and define values go through `JSON.stringify` so a version string stays a string. Both are exactly where copy-pasted configs fail on someone else’s machine.
Proxy rules from a list. Paste one line per backend path (or a full https://host/api URL and let it split) and the tool writes the `server.proxy` block, including the rewrite that strips the prefix and `ws: true` for WebSocket targets. It also flags the traps: a target with no scheme, a duplicate path, and `secure: false`, which disables certificate checking and belongs only in local development.

Nothing is uploaded and nothing is installed: this page only produces text, and the install command it prints is for you to run where you decide. Two honest limits — it does not know which Vite version you are on, so version-specific options are kept to the ones that have been stable for years, and it will not guess your router mode: it only notes that a `base` other than `/` has to be given to a history-mode router as well. For checking an existing config rather than writing a new one, that is a separate tool in this cluster.

FAQ

Is the generated config ready to run?: It is a valid vite.config.ts for a current Vite release, formatted the way Vite’s own docs write it. Read it before committing — the tool cannot know your monorepo layout, your router, or whether your backend really wants the prefix stripped. Everything it generates is standard, documented Vite configuration.
Why fileURLToPath instead of __dirname?: Because a config file with `import` statements is treated as an ES module, where `__dirname` does not exist. `fileURLToPath(new URL("./src", import.meta.url))` is the form that works in both an ESM config and a `type: module` package, which is why it is what the generator emits.
What does the rewrite option do?: With strip on, a request to /api/users is forwarded to <target>/users — that is what you want when the frontend prefix is only a proxy convention. With it off, the prefix is forwarded too, which is what you want when the backend really serves /api/users. The rule table shows which of the two each line produces.
Do I need secure: false?: Only if your development backend uses a self-signed certificate. It disables certificate verification for the proxy, so the tool flags it whenever it appears in a rule — keeping it out of a shared config is the point of the warning, not a formality.
Can it check an existing config?: This page generates; a companion in the same Vite cluster checks. What it can already do here is spot the rules that most often go wrong in review: an alias that points at a package name instead of a path, a define key that is not an identifier or import.meta.env.X, a duplicate alias, and sourcemap enabled for a production build.