Does it run my config?

No. Executing a Vite config means importing your plugins and dependencies, which is exactly what a browser cannot do. The checkup is static: it reads imports, top-level keys, define entries and a handful of options, then compares them with package.json. Everything it reports comes from text you can see, and each finding shows the snippet it is based on.

Why is a plugin missing from package.json an error?

Because it will fail for anyone who does not happen to have it installed globally. The config imports it, so it is a dependency of the build; if it is not in package.json the build on CI, or on a colleague’s machine, breaks. The fix is one line: npm i -D .

What is wrong with define: { X: "1.0.0" }?

Vite replaces the identifier with the text you wrote, so `X` becomes `1.0.0` — a number literal, not a string. Any comparison like `X === "1.0.0"` then fails, and the bug looks like a logic error rather than a config error. Wrapping it in JSON.stringify("1.0.0") is the fix, and the checkup says so explicitly.

Is envPrefix: "" always wrong?

It exposes every environment variable to client code, including any secret that happens to be in the environment. It is occasionally deliberate, but never as a default — the checkup reports it as an error because the failure mode is leaking credentials, and the note tells you what to set instead.

How is this different from the config generator?

The generator writes a new vite.config.ts from checkboxes; this page reviews the one you already have, which is the usual case in an existing project or a migration. They share the same knowledge of what goes wrong — and the generator’s output passes this checkup with no errors or warnings, which is a test we run.

Vite config checkup

Paste your vite.config.ts and package.json: the checkup compares the two and reports what is broken before the build does — a plugin the config imports but nobody installed, a define value that will not be a string, an envPrefix that exposes everything, a target Vite cannot emit.

vite.config.ts (or .js / .mts)

package.json

Both files are analysed as text in this tab — nothing is executed and nothing is uploaded. The checkup never imports your config, so it can review a config you are still editing.

Related: the Vite config generator writes a config from scratch, and the .env validator checks the envPrefix rules on the other side of the same problem.

Findings

3 error(s) · 6 warning(s) · 4 note(s)

Errors (3)

The config imports “rollup-plugin-visualizer” but it is not in dependencies or devDependencies — `npm i -D rollup-plugin-visualizer` or remove the import.import … from 'rollup-plugin-visualizer'
envPrefix is empty, which exposes every environment variable to the client bundle (including secrets). Use a prefix like VITE_.envPrefix: ''
build.target is es5, which Vite does not support for ESM output — you need @vitejs/plugin-legacy instead. target: 'es5'

Warnings (6)

vite is listed under “dependencies”; it is a build tool, so it belongs in devDependencies."dependencies": { "vite": "^5.4.0" }
“lodash” appears in both dependencies and devDependencies — the two lists can drift.lodash: ^4.17.21 / ^4.17.21
“server” appears more than once in the config object; in JavaScript the last one silently wins.server:
define “__APP_VERSION__” is a bare string. Values must be JavaScript expressions — wrap it in JSON.stringify("…") or the replacement is an identifier, not a string.__APP_VERSION__: '1.0.0'
sourcemap: true ships your sources. Fine for staging — usually not for the public build.sourcemap: true
A proxy rule sets secure: false, which disables certificate checking; keep it to local development.secure: false

Notes (4)

package.json has no "build" script; Vite projects normally have "build": "vite build".scripts
“type”: “module” is set, so a .js config file is loaded as ESM — use import/export syntax in it."type": "module"
outDir is outside the project root, so Vite will not empty it automatically — pass emptyOutDir explicitly if you want it cleared.outDir: '../server/public'
An alias is configured in Vite only: your editor needs the same mapping in tsconfig.json paths to resolve it.resolve.alias

Detected

Vite version: ^5
Plugins imported by the config: @vitejs/plugin-vue, rollup-plugin-visualizer

Another validator, not another converter

Configs fail in ways that are hard to see: `plugins: [vue()]` with a package.json that never gained `@vitejs/plugin-vue` works on your machine because it is installed globally, then fails in CI. `define: { __VERSION__: "1.0.0" }` replaces the identifier with `1.0.0` — a number, not the string you meant. `envPrefix: ""` quietly exposes every environment variable, secrets included, to the client bundle.

None of those need a build to find; they only need the config and the manifest side by side. That is exactly what this page does — statically, without running anything:

It compares, it does not guess. Every plugin the config imports is looked up in dependencies and devDependencies; every package listed in optimizeDeps.include is checked against the manifest; a Vue dependency with no @vitejs/plugin-vue import is reported. Deterministic checks, each with the evidence that triggered them — so you can disagree with the tool and see why.
It knows what it cannot know. Your router mode, your deploy path and whether that secret is really a secret are not in these two files. Those come back as notes, phrased as “check this”, not as errors — a checker that invents certainty is worse than no checker.
The traps that cost an afternoon. define values that are not wrapped in JSON.stringify, a duplicated top-level key that silently wins, an optimizeDeps entry that no longer exists, secure: false left in a shared proxy rule, sourcemap: true heading for production, outDir outside the project root without emptyOutDir.

Nothing runs and nothing is uploaded: the analysis is textual, so it works on a config you are still editing and cannot execute anything on your behalf. Two honest limits — it will not catch a config that is syntactically valid but semantically wrong for your app (a base that does not match your deploy path is only a note here), and it does not resolve plugin versions, so a mismatch between the Vite major and a plugin major is not reported. It is the review you would do before a PR, done consistently.

FAQ

Does it run my config?: No. Executing a Vite config means importing your plugins and dependencies, which is exactly what a browser cannot do. The checkup is static: it reads imports, top-level keys, define entries and a handful of options, then compares them with package.json. Everything it reports comes from text you can see, and each finding shows the snippet it is based on.
Why is a plugin missing from package.json an error?: Because it will fail for anyone who does not happen to have it installed globally. The config imports it, so it is a dependency of the build; if it is not in package.json the build on CI, or on a colleague’s machine, breaks. The fix is one line: npm i -D <package>.
What is wrong with define: { X: "1.0.0" }?: Vite replaces the identifier with the text you wrote, so `X` becomes `1.0.0` — a number literal, not a string. Any comparison like `X === "1.0.0"` then fails, and the bug looks like a logic error rather than a config error. Wrapping it in JSON.stringify("1.0.0") is the fix, and the checkup says so explicitly.
Is envPrefix: "" always wrong?: It exposes every environment variable to client code, including any secret that happens to be in the environment. It is occasionally deliberate, but never as a default — the checkup reports it as an error because the failure mode is leaking credentials, and the note tells you what to set instead.
How is this different from the config generator?: The generator writes a new vite.config.ts from checkboxes; this page reviews the one you already have, which is the usual case in an existing project or a migration. They share the same knowledge of what goes wrong — and the generator’s output passes this checkup with no errors or warnings, which is a test we run.