Your Default Vite Config Is Not Enough (New with Vite 8)

Introduction

Last week I was at Vueconf US. It's one of my favorite conferences and I try to go every year. This year Evan You gave a talk on the future of Vue and tooling. Halfway through he started talking about Vite and some of the new features of Vite 8 that just came out. I was amazed at how far Vite has come and the millions of downloads a month it's getting. What I found especially interesting was how few people really knew about these features. Evan asked the audience by a show of hands who had tried out Vite 8, and only a few people raised their hands! So when I got home I decided to write this blog post and create a video on some configurations you must try out with Vite, including some new features that just came out with Vite 8.

If you haven't heard yet, Vite 8 shipped in March 2026 with the most significant architectural change since Vite 2. One of the most significant is the Rust-based bundler called Rolldown that delivers 10-30x faster builds. If you've been using Vite with zero config, that's fine. The defaults are great. However, there are a handful of options that, once you know them, you'll reach for in every project.

This post covers 8 config options that you should know. Two are new in Vite 8, and six have been around but you probably have not heard of them. All of them go in your vite.config.ts.

I put this post together using Kiro, an AI-powered IDE. The forwardConsole option in section 1 is something Kiro benefits from directly.

I also made a video covering all of these with a live demo. Check it out if you prefer watching over reading:

Prerequisites

• Node.js 20.19+ or 22.12+ (required by Vite 8)
• A Vite project (any framework)

To upgrade to Vite 8:

npm install vite@latest

Steps

1. server.forwardConsole

New in Vite 8. When you enable this, browser console errors and warnings show up in your Vite terminal instead of only in DevTools.

export default defineConfig({
  server: {
    forwardConsole: true,
  },
})

It's useful when you're working with AI coding agents that can't see the browser, or when you just want to keep your eyes on the terminal instead of switching to DevTools. Vite auto-enables it when it detects an AI coding agent via @vercel/detect-agent. Otherwise it defaults to false.

You can get more granular with it too:

server: {
  forwardConsole: {
    unhandledErrors: true,
    logLevels: ['warn', 'error'],
  },
}

The output includes source-mapped stack traces, so you see the original TypeScript line numbers, not the compiled output.

2. resolve.tsconfigPaths

Also new in Vite 8. Before this you had to install the vite-tsconfig-paths plugin to use TypeScript path aliases. Now it's built in and works in both the dev server and build.

export default defineConfig({
  resolve: {
    tsconfigPaths: true,
  },
})

One setup mistake I see a lot: make sure paths is inside compilerOptions, not at the top level of the JSON. Easy to get wrong when editing by hand:

// wrong — paths at top level, ignored by Vite
{
  "files": [],
  "paths": { "@/*": ["./src/*"] },
  "references": [{ "path": "./tsconfig.app.json" }]
}

// correct — paths inside compilerOptions
{
  "files": [],
  "references": [{ "path": "./tsconfig.app.json" }],
  "compilerOptions": {
    "paths": {
      "@/*": ["./src/*"],
      "@components/*": ["./src/components/*"]
    }
  }
}

There's a small performance cost, so it's opt-in rather than the default. The TypeScript team also notes that paths is intended to inform TypeScript about mappings handled by other tools, not to change emit behavior. Still, I think it's well worth trying out.

resolve.alias vs resolve.tsconfigPaths: which should you use?

Use tsconfigPaths if you want one place to define aliases and you're already on TypeScript. Use alias for plain JS projects, monorepos, or when you want aliases independent of TypeScript's config.

3. server.proxy

I don't see a lot of developers using this one. The proxy isn't really about fixing CORS. It's about making your dev environment behave like production.

In production, your frontend and API are usually on the same domain. They might have the same origin, so CORS is not needed. For example, in dev, your frontend may be on localhost:5173 and your backend on localhost:8080. If you have different ports, and different origins, tne you'll get a CORS error. The proxy closes helps fix this.

export default defineConfig({
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/api/, ''),
      },
    },
  },
})

Any request to /api/* gets forwarded to http://localhost:8080/*. The browser only ever sees localhost:5173, so no cross-origin request and no CORS error.

A few other reasons to reach for it:

• Working against a teammate's service or a third-party API that hasn't added localhost to their CORS config? You can't change their server, but you can proxy through Vite.
• Adding Access-Control-Allow-Origin: localhost:5173 to your backend is a dev concern leaking into prod config. The proxy keeps that out entirely.
• You can inject auth headers for external services in the proxy configure callback, keeping them out of the browser bundle. This is dev-only though. For production, handle auth server-side.

changeOrigin: true makes the request appear to come from the target host, which some backends require. rewrite strips the /api prefix before forwarding.

4. server.hmr.overlay

By default, Vite shows a full-screen red overlay when there's a server error. Runtime errors, HMR failures, and transform errors all trigger it. If you find it disruptive while editing, you can turn it off.

export default defineConfig({
  server: {
    hmr: {
      overlay: false,
    },
  },
})

Errors still appear in the terminal and browser console. Turn it off when you're doing UI-heavy work and the overlay keeps blocking the component you're editing. I've been turning the overlay off a lot when I work. It's been so much nicer. Leave it on if you like the overlay.

5. resolve.alias

While I prefer the tsconfigpaths, sometimes you have to use resolve.alias instead. It is the explicit way to set up import shortcuts without touching tsconfig at all. It's great for JS projects, monorepos, or when you want aliases that aren't tied to TypeScript's path resolution.

export default defineConfig({
  resolve: {
    alias: {
      '@': path.resolve(__dirname, 'src'),
      '@components': path.resolve(__dirname, 'src/components'),
      '@utils': path.resolve(__dirname, 'src/utils'),
    },
  },
})

Use path.resolve (or fileURLToPath with ESM) to get a proper absolute path. Passing a bare string like '/src' resolves to the filesystem root on most systems, not your project root.

6. server.open

I've been really liking this option. Yes it's small but once you turn it on, you'll never turn it off (at least most of the time). Set server.open: true and Vite opens your browser automatically when the dev server starts.

export default defineConfig({
  server: {
    open: true,
  },
})

You can also pass a path string to land on a specific route:

server: {
  open: '/dashboard',
}

Pairs well with conditional config (see the Bonus section) so you can set open only when running vite dev, not during build.

7. build.sourcemap

By default, Vite doesn't generate sourcemaps for production builds, so errors in production point at minified output. Turn this on and stack traces point at your actual source files.

FYI: Source maps are turned on for dev builds, so don't accidentaly turn this on by accident and leak your source code in production!

export default defineConfig({
  build: {
    sourcemap: true,
  },
})

Run npm run build then npm run preview (preview runs vite preview). Open DevTools, go to Sources, and you'll see your actual .vue and .ts files. Click any line in a stack trace and it jumps to the original source. This is perfect for debugging and adding in break points.

Three modes are available:

build: {
  sourcemap: true,      // separate .map files alongside the bundle
  sourcemap: 'inline',  // sourcemap embedded directly in the JS file
  sourcemap: 'hidden',  // .map files generated, no reference in the bundle
}

'hidden' is useful if you're uploading sourcemaps to an error monitoring service like Sentry. They can decode your stack traces server-side without the browser ever loading the maps. One thing to know: 'hidden' only removes the //# sourceMappingURL= comment from the bundle. The .map files are still generated and will be deployed alongside your JS unless you explicitly exclude them. If you want them truly private, add a step to strip *.map files before uploading. Otherwise your source maps might leak to production!

8. envPrefix

Occasionally I look for this one, it's useful when I'm migrating code and the prefixs are different. By default, Vite only exposes env variables prefixed with VITE_ to your client code. Everything else in your .env file stays server-side. envPrefix lets you change that prefix.

export default defineConfig({
  envPrefix: 'PUBLIC_',
})

With this set, your .env file might look like:

PUBLIC_API_URL=https://api.example.com
PUBLIC_APP_NAME=My App
SECRET_DB_PASSWORD=supersecret

And in your components:

import.meta.env.PUBLIC_API_URL   // "https://api.example.com"
import.meta.env.PUBLIC_APP_NAME  // "My App"
import.meta.env.SECRET_DB_PASSWORD // undefined, never sent to the browser

Only variables matching your prefix make it into the bundle. Everything else is stripped at build time, even if it's in the same .env file.

If you're migrating from Create React App (REACT_APP_) or Next.js (NEXT_PUBLIC_), you can match your existing naming convention instead of renaming every variable. You can also pass an array to expose multiple prefixes:

envPrefix: ['PUBLIC_', 'APP_']

Bonus: conditional config and define

This bonus is more for the advanced users out there! If you are let me know in the comments! You can pass a function to defineConfig instead of an object. It receives command ('serve' or 'build') and mode ('development' or 'production'), so you can change config based on context:

export default defineConfig(({ command, mode }) => ({
  server: {
    open: command === 'serve',
  },
  build: {
    sourcemap: mode !== 'production',
  },
}))

define bakes global constants into the build at compile time. Values are inlined directly into the output, so there's no runtime cost:

define: {
  __APP_VERSION__: JSON.stringify('1.0.0'),
  __BUILD_DATE__: JSON.stringify(new Date().toISOString()),
}

Add type declarations to vite-env.d.ts so TypeScript knows about them:

declare const __APP_VERSION__: string
declare const __BUILD_DATE__: string

Cleanup

Most of these are config-only changes. A few touch other files: tsconfigPaths requires paths in your tsconfig.json, envPrefix pairs with a .env file, and define needs type declarations in vite-env.d.ts. To revert any option, remove it from vite.config.ts and Vite falls back to its defaults.

Frequently Asked Questions

Why aren't my TypeScript path aliases working in Vite?
Make sure paths is inside compilerOptions in your tsconfig.json, not at the top level. Vite 8's built-in resolve.tsconfigPaths: true reads from compilerOptions.paths only. A top-level paths key is silently ignored.

What's the difference between resolve.alias and resolve.tsconfigPaths in Vite?
resolve.alias is defined directly in vite.config.ts and works for any project including plain JavaScript. resolve.tsconfigPaths reads aliases from your tsconfig.json and requires TypeScript. Use tsconfigPaths if you want a single source of truth; use alias for JS projects or monorepos.

Does Vite's server.proxy fix CORS errors?
Yes, but the real purpose is making dev match production. The proxy routes requests through the Vite dev server so the browser never makes a cross-origin request. No CORS header needed on your backend. It's cleaner than adding Access-Control-Allow-Origin: localhost:5173 to your server config.

Are Vite production sourcemaps safe to deploy?
sourcemap: 'hidden' generates .map files without referencing them in the bundle, so browsers won't load them. You can upload them to Sentry or similar for private stack trace decoding. Note: the .map files are still built and will be deployed unless you add a step to strip *.map files before uploading.

What env variables does Vite expose to the browser?
Only variables prefixed with VITE_ by default (or your custom envPrefix). Everything else in .env is stripped at build time and never sent to the browser. That includes secrets like database passwords or API keys that don't have the prefix.

Does server.forwardConsole work with all frameworks?
Yes, it's a Vite dev server feature, not framework-specific. It works with Vue, React, Svelte, and any other Vite-based setup. Vite auto-enables it when it detects an AI coding agent via @vercel/detect-agent; otherwise it defaults to false.

Conclusion

forwardConsole and tsconfigPaths are both opt-in and default to false. The others (proxy, hmr.overlay, resolve.alias, server.open, build.sourcemap, envPrefix) have been around for a while but are easy to miss if you've never needed them.

The full demo project is available at https://github.com/ErikCH/vite-config-tips.

Here is me speaking at VueConf this year!

Written by Erik Hanchett, AWS Developer Advocate. He covers frontend development, AWS, and AI/agents at programwitherik.com.