```
This will be modified [with the result of a file import](https://github.com/vitejs/vite/blob/v6.3.1/playground/assets/index.html#L543-L544):
```js
import rawSvg from './nested/fragment.svg?raw'
text('.raw', rawSvg)
```
...where the `text` util is defined as:
```js
function text(el, text) {
document.querySelector(el).textContent = text
}
```
In the [spec tests](https://github.com/vitejs/vite/blob/v6.3.1/playground/assets/__tests__/assets.spec.ts#L469-L471), the modifications to the DOM listed above are used to test this feature:
```js
test('?raw import', async () => {
expect(await page.textContent('.raw')).toMatch('SVG')
})
```
### Note on Test Dependencies
In many test cases, we need to mock dependencies using `link:` and `file:` protocols. `pnpm` treats `link:` as symlinks and `file:` as hardlinks. To test dependencies as if they were copied into `node_modules`, use the `file:` protocol. Otherwise, use the `link:` protocol.
For a mock dependency, make sure you add a `@vitejs/test-` prefix to the package name. This will avoid possible issues like false-positive alerts.
## Pull Request Guidelines
> [!NOTE]
> You do not need to ask for permission to work on an open issue. You can start investigating or open a PR directly. If someone else ships a fix first, you can still help by reviewing or validating the solution.
- Checkout a topic branch from a base branch (e.g. `main`), and merge back against that branch.
- If adding a new feature:
- Add accompanying test case.
- Provide a convincing reason to add this feature. Ideally, you should open a suggestion issue first, and have it approved before working on it.
- If fixing a bug:
- If you are resolving a special issue, add `(fix #xxxx[,#xxxx])` (#xxxx is the issue id) in your PR title for a better release log (e.g. `fix: update entities encoding/decoding (fix #3899)`).
- Provide a detailed description of the bug in the PR. Live demo preferred.
- Add appropriate test coverage. If not applicable, explain in the PR description why tests are not included.
- If it's a chore:
- For typos and comment changes, try to combine multiple of them into a single PR.
- **Note that we discourage contributors from submitting code refactors that are largely stylistic.** Code refactors are only accepted if it improves performance, or objectively improves code quality (e.g. makes a related bug fix or feature implementation easier, and it is as a separate PR to improve git history).
- The reason is that code readability is subjective. The maintainers of this project have chosen to write the code in its current style based on our preferences, and we do not want to spend time explaining our stylistic preferences. Contributors should just respect the established conventions when contributing code. Another aspect of it is that large scale stylistic changes result in massive diffs that touch multiple files, adding noise to the git history and makes tracing behavior changes across commits more cumbersome.
- It's OK to have multiple small commits as you work on the PR. GitHub can automatically squash them before merging.
- Make sure tests pass!
- No need to worry about code style as long as you have installed the dev dependencies. Modified files are automatically formatted with Prettier on commit (by invoking [Git Hooks](https://git-scm.com/docs/githooks) via [simple-git-hooks](https://github.com/toplenboren/simple-git-hooks)).
- PR title must follow the [commit message convention](./.github/commit-convention.md) so that changelogs can be automatically generated.
## Maintenance Guidelines
> The following section is mostly for maintainers who have commit access, but it's helpful to go through if you intend to make non-trivial contributions to the codebase.
### Issue Triaging Workflow
```mermaid
flowchart TD
start{Followed issue
template?}
start --NO--> close1["Close and ask to
follow template"]
start --YES--> dupe{Is duplicate?}
dupe --YES--> close2[Close and point
to duplicate]
dupe --NO--> repro{Has proper
reproduction?}
repro --NO--> close3[Label: 'needs reproduction'
bot will auto close if no update
has been made in 3 days]
repro --YES--> real{Is actually a bug?}
real --NO--> intended{Is the intended
behaviour?}
intended --YES--> explain[Explain and close
point to docs if needed]
intended --NO--> open[Keep open for discussion
Remove 'pending triage' label]
real --YES--> real2["① Remove 'pending triage' label
② Add related feature label if applicable
(e.g. 'feat: ssr')
③ Add priority and meta labels (see below)"]
real2 --> unusable{Does the
bug make Vite
unusable?}
unusable --YES--> maj{Does the bug
affect the majority
of Vite users?}
maj --YES--> p5[p5: urgent]
maj --NO--> p4[p4: important]
unusable --NO--> workarounds{Are there
workarounds for
the bug?}
workarounds --NO--> p3[p3: minor bug]
workarounds --YES--> p2[p2: edge case
has workaround]
```
### Pull Request Review Workflow
```mermaid
flowchart TD
start{Bug fix
or
feature}
start --BUG FIX--> strict_bug{"Is this a 'strict fix'?
i.e. fixes an obvious oversight with no side effects"}
start --FEATURE--> feature[• Discuss feature necessity
• Is there a better way to address the need?
• Review code quality
• Add labels
• Add to milestone
• Add to Team Board]
feature -.-> approve_non_strict[• Run vite-ecosystem-ci if needed
• Approve if you feel strongly that the PR is needed and add to milestone]
strict_bug --YES--> strict[• Verify the fix locally
• Review code quality
• Require test case if applicable
• Request changes if necessary
• Add labels]
strict_bug --NO--> non_strict[Discuss the potential side effects of the fix, e.g.
• Could it introduce implicit behavior changes in other cases?
• Does it introduce too much changes?
• Add labels
• Add to Team Board]
non_strict -.-> approve_non_strict
strict --> approve_strict[Approve if ready to be merged]
approve_strict --> merge_strict[Merge if approved by 2 or more team members]
approve_non_strict -.-> merge_non_strict[Merge if approved by 2 or more team members and the PR has been discussed in a team meeting]
merge_non_strict -.-> merge_extra
merge_strict --> merge_extra["• Use 'Squash and Merge'
• Edit commit message to follow convention
• In commit message body, list relevant issues being fixed e.g. 'fix #1234, fix #1235'"]
```
### Release
If you have publish access, the steps below explain how to cut a release for a package. There are two phases for the release step: "Release" and "Publish".
"Release" is done locally to generate the changelogs and git tags:
1. Make sure the git remote for https://github.com/vitejs/vite is set as `origin`.
2. In the `vite` project root `main` branch, run `git pull` and `pnpm i` to get it up-to-date. Then run `pnpm build`.
3. Run `pnpm release` and follow the prompts to cut a release for a package. It will generate the changelog, a git release tag, and push them to `origin`. You can run with the `--dry` flag to test it out.
4. When the command finishes, it will provide a link to https://github.com/vitejs/vite/actions/workflows/publish.yml.
5. Click the link to visit the page, and follow the next steps below.
"Publish" is done on GitHub Actions to publish the package to npm:
1. Shortly in the workflows page, a new workflow will appear for the released package and is waiting for approval to publish to npm.
2. Click on the workflow to open its page.
3. Click on the "Review deployments" button in the yellow box, a popup will appear.
4. Check "Release" and click "Approve and deploy".
5. The package will start publishing to npm.
To learn more about how and when Vite does releases, check out the [Releases](https://vite.dev/releases) documentation.
================================================
FILE: LICENSE
================================================
MIT License
Copyright (c) 2019-present, VoidZero Inc. and Vite contributors
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
================================================
FILE: README.md
================================================
Building Together
ViteConf 2025
View the replays
If you're using Vite , it is {{ checkedResult.text }}.
Don't take our word for it - listen to what Vite community members have to say.
Weekly NPM downloads
{{ paragraph }}
On demand source file serving over native ESM, with blazing fast dependency pre-bundling.
Instantly reflect changes as you save, no matter how big your app is.
TypeScript, JSX, CSS, Workers, WebAssembly... and more just a plugin away.
Advanced tree-shaking, built-in minification, fine-grained chunking control powered by Rolldown.
Vite plugins extends Rollup's well-designed plugin interface with a few extra Vite-specific options.
Designed to be built on top of.
It's never been easier to setup custom SSR (Server-Side Rendering), or build your own SSR framework.
Our CI continuously tests Vite changes against downstream projects, allowing us to improve Vite with stability and confidence.
Vite is a blazing fast frontend build tool powering the next generation of web applications.
Vite: The Documentary re-premiere
Join the ecosystem this March 19th at 3 PM UTC to remember the story we wrote together. And participate in the live stage to discuss our past, present, and future. We'll be waiting for you!
{{ dep.description }}
| Author | Packages |
|---|---|
| {{ author.name }} {{ author.name }} Sponsor |
{{ pkg.name }}Sponsor,
|
{{ dep.description }}
| Package | Description | Links |
|---|---|---|
{{ dep.name }} |
{{ dep.description }} | Repo |
VITE v3.0.0 ready in 320 ms ➜ Local: http://127.0.0.1:5173/ ➜ Network: use --host to exposeApart from the CLI’s aesthetics improvements, you’ll notice that the default dev server port is now 5173 and the preview server listening at 4173. This change ensures Vite will avoid collisions with other tools. ### Improved WebSocket Connection Strategy One of the pain points of Vite 2 was configuring the server when running behind a proxy. Vite 3 changes the default connection scheme so it works out of the box in most scenarios. All these setups are now tested as part of the Vite Ecosystem CI through [`vite-setup-catalogue`](https://github.com/sapphi-red/vite-setup-catalogue). ### Cold Start Improvements Vite now avoids full reload during cold start when imports are injected by plugins while crawling the initial statically imported modules ([#8869](https://github.com/vitejs/vite/issues/8869)).
Omit<RolldownOptions, 'input' | 'logLevel' | 'output'> & { output?: Omit<RolldownOutputOptions, 'format' | 'sourcemap' | 'dir' | 'banner'> }
Options to pass to Rolldown during the dep scanning and optimization.
Certain options are omitted since changing them would not be compatible with Vite's dep optimization.
- `plugins` are merged with Vite's dep plugin
## optimizeDeps.esbuildOptions Omit<EsbuildBuildOptions, 'bundle' | 'entryPoints' | 'external' | 'write' | 'watch' | 'outdir' | 'outfile' | 'outbase' | 'outExtension' | 'metafile'>
- **Deprecated**
This option is converted to `optimizeDeps.rolldownOptions` internally. Use `optimizeDeps.rolldownOptions` instead.
## optimizeDeps.force Using data from %VITE_API_URL%
``` If the env doesn't exist in `import.meta.env`, e.g. `%NON_EXISTENT%`, it will be ignored and not replaced, unlike `import.meta.env.NON_EXISTENT` in JS where it's replaced as `undefined`. Given that Vite is used by many frameworks, it is intentionally unopinionated about complex replacements like conditionals. Vite can be extended using [an existing userland plugin](https://github.com/vitejs/awesome-vite#transformers) or a custom plugin that implements the [`transformIndexHtml` hook](./api-plugin#transformindexhtml). ## Modes By default, the dev server (`dev` command) runs in `development` mode and the `build` command runs in `production` mode. This means when running `vite build`, it will load the env variables from `.env.production` if there is one: ```[.env.production] VITE_APP_TITLE=My App ``` In your app, you can render the title using `import.meta.env.VITE_APP_TITLE`. In some cases, you may want to run `vite build` with a different mode to render a different title. You can overwrite the default mode used for a command by passing the `--mode` option flag. For example, if you want to build your app for a staging mode: ```bash vite build --mode staging ``` And create a `.env.staging` file: ```[.env.staging] VITE_APP_TITLE=My App (staging) ``` As `vite build` runs a production build by default, you can also change this and run a development build by using a different mode and `.env` file configuration: ```[.env.testing] NODE_ENV=development ``` ### NODE_ENV and Modes It's important to note that `NODE_ENV` (`process.env.NODE_ENV`) and modes are two different concepts. Here's how different commands affect the `NODE_ENV` and mode: | Command | NODE_ENV | Mode | | ---------------------------------------------------- | --------------- | --------------- | | `vite build` | `"production"` | `"production"` | | `vite build --mode development` | `"production"` | `"development"` | | `NODE_ENV=development vite build` | `"development"` | `"production"` | | `NODE_ENV=development vite build --mode development` | `"development"` | `"development"` | The different values of `NODE_ENV` and mode also reflect on its corresponding `import.meta.env` properties: | Command | `import.meta.env.PROD` | `import.meta.env.DEV` | | ---------------------- | ---------------------- | --------------------- | | `NODE_ENV=production` | `true` | `false` | | `NODE_ENV=development` | `false` | `true` | | `NODE_ENV=other` | `false` | `true` | | Command | `import.meta.env.MODE` | | -------------------- | ---------------------- | | `--mode production` | `"production"` | | `--mode development` | `"development"` | | `--mode staging` | `"staging"` | :::tip `NODE_ENV` in `.env` files `NODE_ENV=...` can be set in the command, and also in your `.env` file. If `NODE_ENV` is specified in a `.env.[mode]` file, the mode can be used to control its value. However, both `NODE_ENV` and modes remain as two different concepts. The main benefit with `NODE_ENV=...` in the command is that it allows Vite to detect the value early. It also allows you to read `process.env.NODE_ENV` in your Vite config as Vite can only load the env files once the config is evaluated. ::: ================================================ FILE: docs/guide/features.md ================================================ # Features 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. ## npm Dependency Resolving and Pre-Bundling Native ES imports do not support bare module imports like the following: ```js import { someMethod } from 'my-dep' ``` 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: 1. [Pre-bundle](./dep-pre-bundling) them to improve page loading speed and convert CommonJS / UMD modules to ESM. The pre-bundling step is performed with [esbuild](https://esbuild.github.io/) and makes Vite's cold start time significantly faster than any JavaScript-based bundler. 2. 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](./dep-pre-bundling#browser-cache). ## Hot Module Replacement Vite provides an [HMR API](./api-hmr) 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](https://github.com/vitejs/vite-plugin-vue/tree/main/packages/plugin-vue) and [React Fast Refresh](https://github.com/vitejs/vite-plugin-react/tree/main/packages/plugin-react). There are also official integrations for Preact via [@prefresh/vite](https://github.com/JoviDeCroock/prefresh/tree/main/packages/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. ## TypeScript Vite supports importing `.ts` files out of the box. ### Transpile Only 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](https://github.com/fi3ework/vite-plugin-checker) if you prefer having type errors directly reported in the browser. Vite uses [esbuild](https://github.com/evanw/esbuild) to transpile TypeScript into JavaScript which is about 20~30x faster than vanilla `tsc`, and HMR updates can reflect in the browser in under 50ms. Use the [Type-Only Imports and Export](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html#type-only-imports-and-export) syntax to avoid potential problems like type-only imports being incorrectly bundled, for example: ```ts import type { T } from 'only/types' export type { T } ``` ### TypeScript Compiler Options Vite respects some of the options in `tsconfig.json` and sets the corresponding esbuild options. For each file, Vite uses the `tsconfig.json` in the closest parent directory. If that `tsconfig.json` contains a [`references`](https://www.typescriptlang.org/tsconfig/#references) field, Vite will use the referenced config file that satisfies the [`include`](https://www.typescriptlang.org/tsconfig/#include) and [`exclude`](https://www.typescriptlang.org/tsconfig/#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. #### `isolatedModules` - [TypeScript documentation](https://www.typescriptlang.org/tsconfig#isolatedModules) Should be set to `true`. It is because `esbuild` 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. #### `useDefineForClassFields` - [TypeScript documentation](https://www.typescriptlang.org/tsconfig#useDefineForClassFields) 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+](https://github.com/microsoft/TypeScript/pull/42663). 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. #### `target` - [TypeScript documentation](https://www.typescriptlang.org/tsconfig#target) Vite ignores the `target` value in the `tsconfig.json`, following the same behavior as `esbuild`. To specify the target in dev, the [`esbuild.target`](/config/shared-options.html#esbuild) option can be used, which defaults to `esnext` for minimal transpilation. In builds, the [`build.target`](/config/build-options.html#build-target) option takes higher priority over `esbuild.target` and can also be set if needed. #### `emitDecoratorMetadata` - [TypeScript documentation](https://www.typescriptlang.org/tsconfig#emitDecoratorMetadata) This option is only partially supported. Full support requires type inference by the TypeScript compiler, which is not supported. See [Oxc Transformer's documentation](https://oxc.rs/docs/guide/usage/transformer/typescript#decorators) for details. #### `paths` - [TypeScript documentation](https://www.typescriptlang.org/tsconfig/#paths) `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](https://www.typescriptlang.org/tsconfig/#paths:~:text=Note%20that%20this%20feature%20does%20not%20change%20how%20import%20paths%20are%20emitted%20by%20tsc%2C%20so%20paths%20should%20only%20be%20used%20to%20inform%20TypeScript%20that%20another%20tool%20has%20this%20mapping%20and%20will%20use%20it%20at%20runtime%20or%20when%20bundling.). #### Other Compiler Options Affecting the Build Result - [`extends`](https://www.typescriptlang.org/tsconfig#extends) - [`importsNotUsedAsValues`](https://www.typescriptlang.org/tsconfig#importsNotUsedAsValues) - [`preserveValueImports`](https://www.typescriptlang.org/tsconfig#preserveValueImports) - [`verbatimModuleSyntax`](https://www.typescriptlang.org/tsconfig#verbatimModuleSyntax) - [`jsx`](https://www.typescriptlang.org/tsconfig#jsx) - [`jsxFactory`](https://www.typescriptlang.org/tsconfig#jsxFactory) - [`jsxFragmentFactory`](https://www.typescriptlang.org/tsconfig#jsxFragmentFactory) - [`jsxImportSource`](https://www.typescriptlang.org/tsconfig#jsxImportSource) - [`experimentalDecorators`](https://www.typescriptlang.org/tsconfig#experimentalDecorators) ::: tip `skipLibCheck` 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](https://github.com/vuejs/vue-cli/pull/5688). ::: ### Client Types Vite's default types are for its Node.js API. To shim the environment of client-side code in a Vite application, you can add `vite/client` to `compilerOptions.types` inside `tsconfig.json`: ```json [tsconfig.json] { "compilerOptions": { "types": ["vite/client", "some-other-global-lib"] } } ``` Note that if [`compilerOptions.types`](https://www.typescriptlang.org/tsconfig#types) is specified, only these packages will be included in the global scope (instead of all visible ”@types” packages). This is recommended since TS 5.9. ::: details Using triple-slash directive Alternatively, you can add a `d.ts` declaration file: ```typescript [vite-env.d.ts] ///