Features | Vite

Dependency Pre-Bundling
Static Asset Handling
Building for Production
Deploying a Static Site
Env Variables and Modes
Server-Side Rendering (SSR)
Environment Instances
At the very basic level, developing using Vite is not that different from using a static file server. However, Vite provides many enhancements over native ESM imports to support various features that are typically seen in bundler-based setups.
Native ES imports do not support bare module imports like the following:
The above import will throw an error in the browser. Vite will detect such bare module imports in all served source files and perform the following:
Pre-bundle them to improve page loading speed and convert CommonJS / UMD modules to ESM. The pre-bundling step is performed with Rolldown and makes Vite's cold start time significantly faster than any JavaScript-based bundler.
Rewrite the imports to valid URLs like /node_modules/.vite/deps/my-dep.js?v=f3sf2ebd so that the browser can import them properly.
Dependencies are Strongly Cached
Vite caches dependency requests via HTTP headers, so if you wish to locally edit/debug a dependency, follow the steps here.
Vite provides an HMR API over native ESM. Frameworks with HMR capabilities can leverage the API to provide instant, precise updates without reloading the page or blowing away application state. Vite provides first-party HMR integrations for Vue Single File Components and React Fast Refresh. There are also official integrations for Preact via @prefresh/vite.
Note you don't need to manually set these up - when you create an app via create-vite, the selected templates would have these pre-configured for you already.
Vite supports importing .ts files out of the box.
Note that Vite only performs transpilation on .ts files and does NOT perform type checking. It assumes type checking is taken care of by your IDE and build process.
The reason Vite does not perform type checking as part of the transform process is because the two jobs work fundamentally differently. Transpilation can work on a per-file basis and aligns perfectly with Vite's on-demand compile model. In comparison, type checking requires knowledge of the entire module graph. Shoe-horning type checking into Vite's transform pipeline will inevitably compromise Vite's speed benefits.
Vite's job is to get your source modules into a form that can run in the browser as fast as possible. To that end, we recommend separating static analysis checks from Vite's transform pipeline. This principle applies to other static analysis checks such as ESLint.
For production builds, you can run tsc --noEmit in addition to Vite's build command.
During development, if you need more than IDE hints, we recommend running tsc --noEmit --watch in a separate process, or use vite-plugin-checker if you prefer having type errors directly reported in the browser.
Vite uses Oxc Transformer to transpile TypeScript into JavaScript which is faster than vanilla tsc, and HMR updates can reflect in the browser in under 50ms.
Use the Type-Only Imports and Export syntax to avoid potential problems like type-only imports being incorrectly bundled, for example:
Vite respects some of the options in tsconfig.json and sets the corresponding Oxc Transformer options. By default, Vite uses the closest parent tsconfig.json that matches each file. A config referenced by that config's references field is used when it matches the file. Vite treats a config as matching the file when the file satisfies the config's files, include, and exclude fields.
When the options are set in both the Vite config and the tsconfig.json, the value in the Vite config takes precedence.
Some configuration fields under compilerOptions in tsconfig.json require special attention.
Should be set to true.
It is because Oxc transformer only performs transpilation without type information, it doesn't support certain features like const enum and implicit type-only imports.
You must set "isolatedModules": true in your tsconfig.json under compilerOptions, so that TS will warn you against the features that do not work with isolated transpilation.
If a dependency doesn't work well with "isolatedModules": true, you can use "skipLibCheck": true to temporarily suppress the errors until it is fixed upstream.
The default value will be true if the TypeScript target is ES2022 or newer including ESNext. It is consistent with the behavior of TypeScript 4.3.2+. Other TypeScript targets will default to false.
true is the standard ECMAScript runtime behavior.
If you are using a library that heavily relies on class fields, please be careful about the library's intended usage of it. While most libraries expect "useDefineForClassFields": true, you can explicitly set useDefineForClassFields to false if your library doesn't support it.
Vite ignores the target value in the tsconfig.json, following the same behavior as esbuild.
To specify the target in dev, the oxc.target option can be used, which defaults to esnext for minimal transpilation. In builds, the build.target option takes higher priority over oxc.target and can also be set if needed.
This option is only partially supported. Full support requires type inference by the TypeScript compiler, which is not supported. See Oxc Transformer's documentation for details.
resolve.tsconfigPaths: true can be specified to tell Vite to use the paths option in tsconfig.json to resolve imports.
Note that this feature has a performance cost and is discouraged by the TypeScript team to use this option to change the behavior of the external tools.
Vite starter templates have "skipLibCheck": true by default to avoid typechecking dependencies, as they may choose to only support specific versions and configurations of TypeScript. You can learn more at vuejs/vue-cli#5688.