mirror of
https://github.com/vitejs/vite.git
synced 2024-11-21 22:59:10 +00:00
docs: fix typos (#9776)
This commit is contained in:
parent
9206ad7c1c
commit
81989bfb32
@ -254,7 +254,7 @@ We want to thank everyone that have implemented features, and fixes, given feedb
|
||||
- Vite team members [@youyuxi](https://twitter.com/youyuxi), [@patak_dev](https://twitter.com/patak_dev), [@antfu7](https://twitter.com/antfu7), [@bluwyoo](https://twitter.com/bluwyoo), [@sapphi_red](https://twitter.com/sapphi_red), [@haoqunjiang](https://twitter.com/haoqunjiang), [@poyoho](https://github.com/poyoho), [@Shini_92](https://twitter.com/Shini_92), and [@retropragma](https://twitter.com/retropragma).
|
||||
- [@benmccann](https://github.com/benmccann), [@danielcroe](https://twitter.com/danielcroe), [@brillout](https://twitter.com/brillout), [@sheremet_va](https://twitter.com/sheremet_va), [@userquin](https://twitter.com/userquin), [@enzoinnocenzi](https://twitter.com/enzoinnocenzi), [@maximomussini](https://twitter.com/maximomussini), [@IanVanSchooten](https://twitter.com/IanVanSchooten), the [Astro team](https://astro.build/), and all other maintainers of frameworks and plugins in the ecosystem in that helped shape v3.
|
||||
- [@dominikg](https://github.com/dominikg) for his work on vite-ecosystem-ci.
|
||||
- [@ZoltanKochan](https://twitter.com/ZoltanKochan) for his work on [pnpm](https://pnpm.io/), and for his responsivness when we needed support with it.
|
||||
- [@ZoltanKochan](https://twitter.com/ZoltanKochan) for his work on [pnpm](https://pnpm.io/), and for his responsiveness when we needed support with it.
|
||||
- [@rixo](https://github.com/rixo) for HMR Partial Accept support.
|
||||
- [@KiaKing85](https://twitter.com/KiaKing85) for getting the theme ready for the Vite 3 release, and [@\_brc_dd](https://twitter.com/_brc_dd) for working on the VitePress internals.
|
||||
- [@CodingWithCego](https://twitter.com/CodingWithCego) for the new Spanish translation, and [@ShenQingchuan](https://twitter.com/ShenQingchuan), [@hiro-lapis](https://github.com/hiro-lapis) and others in the Chinese and Japanese translations teams for keeping the translated docs up to date.
|
||||
|
@ -13,7 +13,7 @@ Another special value is `'esnext'` - which assumes native dynamic imports suppo
|
||||
- If the [`build.minify`](#build-minify) option is `'terser'`, `'esnext'` will be forced down to `'es2021'`.
|
||||
- In other cases, it will perform no transpilation at all.
|
||||
|
||||
The transform is performed with esbuild and the value should be a valid [esbuild target option](https://esbuild.github.io/api/#target). Custom targets can either be a ES version (e.g. `es2015`), a browser with version (e.g. `chrome58`), or an array of multiple target strings.
|
||||
The transform is performed with esbuild and the value should be a valid [esbuild target option](https://esbuild.github.io/api/#target). Custom targets can either be an ES version (e.g. `es2015`), a browser with version (e.g. `chrome58`), or an array of multiple target strings.
|
||||
|
||||
Note the build will fail if the code contains features that cannot be safely transpiled by esbuild. See [esbuild docs](https://esbuild.github.io/content-types/#javascript) for more details.
|
||||
|
||||
@ -75,7 +75,7 @@ If you specify `build.lib`, `build.cssCodeSplit` will be `false` as default.
|
||||
- **Type:** `string | string[]`
|
||||
- **Default:** the same as [`build.target`](#build-target)
|
||||
|
||||
This options allows users to set a different browser target for CSS minification from the one used for JavaScript transpilation.
|
||||
This option allows users to set a different browser target for CSS minification from the one used for JavaScript transpilation.
|
||||
|
||||
It should only be used when you are targeting a non-mainstream browser.
|
||||
One example is Android WeChat WebView, which supports most modern JavaScript features but not the [`#RGBA` hexadecimal color notation in CSS](https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#rgb_colors).
|
||||
@ -128,7 +128,7 @@ When set to `true`, the build will also generate a `manifest.json` file that con
|
||||
- **Default:** `false`
|
||||
- **Related:** [Server-Side Rendering](/guide/ssr)
|
||||
|
||||
When set to `true`, the build will also generate a SSR manifest for determining style links and asset preload directives in production. When the value is a string, it will be used as the manifest file name.
|
||||
When set to `true`, the build will also generate an SSR manifest for determining style links and asset preload directives in production. When the value is a string, it will be used as the manifest file name.
|
||||
|
||||
## build.ssr
|
||||
|
||||
@ -145,7 +145,7 @@ Produce SSR-oriented build. The value can be a string to directly specify the SS
|
||||
|
||||
Set to `false` to disable minification, or specify the minifier to use. The default is [esbuild](https://github.com/evanw/esbuild) which is 20 ~ 40x faster than terser and only 1 ~ 2% worse compression. [Benchmarks](https://github.com/privatenumber/minification-benchmarks)
|
||||
|
||||
Note the `build.minify` option does not minify whitespaces when using the `'es'` format in lib mode, as it removes pure annotations and break tree-shaking.
|
||||
Note the `build.minify` option does not minify whitespaces when using the `'es'` format in lib mode, as it removes pure annotations and breaks tree-shaking.
|
||||
|
||||
Terser must be installed when it is set to `'terser'`.
|
||||
|
||||
|
@ -8,7 +8,7 @@
|
||||
|
||||
By default, Vite will crawl all your `.html` files to detect dependencies that need to be pre-bundled (ignoring `node_modules`, `build.outDir`, `__tests__` and `coverage`). If `build.rollupOptions.input` is specified, Vite will crawl those entry points instead.
|
||||
|
||||
If neither of these fit your needs, you can specify custom entries using this option - the value should be a [fast-glob pattern](https://github.com/mrmlnc/fast-glob#basic-syntax) or array of patterns that are relative from Vite project root. This will overwrite default entries inference. Only `node_modules` and `build.outDir` folders will be ignored by default when `optimizeDeps.entries` is explicitly defined. If other folders needs to be ignored, you can use an ignore pattern as part of the entries list, marked with an initial `!`.
|
||||
If neither of these fit your needs, you can specify custom entries using this option - the value should be a [fast-glob pattern](https://github.com/mrmlnc/fast-glob#basic-syntax) or array of patterns that are relative from Vite project root. This will overwrite default entries inference. Only `node_modules` and `build.outDir` folders will be ignored by default when `optimizeDeps.entries` is explicitly defined. If other folders need to be ignored, you can use an ignore pattern as part of the entries list, marked with an initial `!`.
|
||||
|
||||
## optimizeDeps.exclude
|
||||
|
||||
|
@ -86,7 +86,7 @@ export default defineConfig(async ({ command, mode }) => {
|
||||
|
||||
Environmental Variables can be obtained from `process.env` as usual.
|
||||
|
||||
Note that Vite doesn't load `.env` files by default as the files to load can only be determined after evaluating the Vite config, for example, the `root` and `envDir` options affects the loading behaviour. However, you can use the exported `loadEnv` helper to load the specific `.env` file if needed.
|
||||
Note that Vite doesn't load `.env` files by default as the files to load can only be determined after evaluating the Vite config, for example, the `root` and `envDir` options affect the loading behaviour. However, you can use the exported `loadEnv` helper to load the specific `.env` file if needed.
|
||||
|
||||
```js
|
||||
import { defineConfig, loadEnv } from 'vite'
|
||||
|
@ -14,7 +14,7 @@ This can be set via the CLI using `--host 0.0.0.0` or `--host`.
|
||||
|
||||
There are cases when other servers might respond instead of Vite.
|
||||
|
||||
The first case is when `localhost` is used. Node.js under v17 reorders the result of DNS-resolved address by default. When accessing `localhost`, browsers use DNS to resolve the address and that address might differ from the address which Vite is listening. Vite prints the resolved address when it differs.
|
||||
The first case is when `localhost` is used. Node.js under v17 reorders the result of DNS-resolved addresses by default. When accessing `localhost`, browsers use DNS to resolve the address and that address might differ from the address which Vite is listening to. Vite prints the resolved address when it differs.
|
||||
|
||||
You can set [`dns.setDefaultResultOrder('verbatim')`](https://nodejs.org/api/dns.html#dns_dns_setdefaultresultorder_order) to disable the reordering behavior. Vite will then print the address as `localhost`.
|
||||
|
||||
@ -30,7 +30,7 @@ export default defineConfig({
|
||||
})
|
||||
```
|
||||
|
||||
The second case is when wildcard hosts (e.g. `0.0.0.0`) is used. This is because servers listening on non-wildcard hosts take priority over those listening on wildcard hosts.
|
||||
The second case is when wildcard hosts (e.g. `0.0.0.0`) are used. This is because servers listening on non-wildcard hosts take priority over those listening on wildcard hosts.
|
||||
|
||||
:::
|
||||
|
||||
@ -149,7 +149,7 @@ Check out [`vite-setup-catalogue`](https://github.com/sapphi-red/vite-setup-cata
|
||||
|
||||
::: tip NOTE
|
||||
|
||||
With the default configuration, reverse proxies in front of Vite are expected to support proxying WebSocket. If the Vite HMR client fails to connect WebSocket, the client will fallback to connecting the WebSocket directly to the Vite HMR server bypassing the reverse proxies:
|
||||
With the default configuration, reverse proxies in front of Vite are expected to support proxying WebSocket. If the Vite HMR client fails to connect WebSocket, the client will fall back to connecting the WebSocket directly to the Vite HMR server bypassing the reverse proxies:
|
||||
|
||||
```
|
||||
Direct websocket connection fallback. Check out https://vitejs.dev/config/server-options.html#server-hmr to remove the previous connection error.
|
||||
@ -255,7 +255,7 @@ Restrict serving files outside of workspace root.
|
||||
|
||||
Restrict files that could be served via `/@fs/`. When `server.fs.strict` is set to `true`, accessing files outside this directory list that aren't imported from an allowed file will result in a 403.
|
||||
|
||||
Vite will search for the root of the potential workspace and use it as default. A valid workspace met the following conditions, otherwise will fallback to the [project root](/guide/#index-html-and-project-root).
|
||||
Vite will search for the root of the potential workspace and use it as default. A valid workspace met the following conditions, otherwise will fall back to the [project root](/guide/#index-html-and-project-root).
|
||||
|
||||
- contains `workspaces` field in `package.json`
|
||||
- contains one of the following file
|
||||
|
@ -336,10 +336,10 @@ See [here](/guide/env-and-mode#env-files) for more about environment files.
|
||||
- **Type:** `string | string[]`
|
||||
- **Default:** `VITE_`
|
||||
|
||||
Env variables starts with `envPrefix` will be exposed to your client source code via import.meta.env.
|
||||
Env variables starting with `envPrefix` will be exposed to your client source code via import.meta.env.
|
||||
|
||||
:::warning SECURITY NOTES
|
||||
`envPrefix` should not be set as `''`, which will expose all your env variables and cause unexpected leaking of of sensitive information. Vite will throw error when detecting `''`.
|
||||
`envPrefix` should not be set as `''`, which will expose all your env variables and cause unexpected leaking of sensitive information. Vite will throw an error when detecting `''`.
|
||||
:::
|
||||
|
||||
## appType
|
||||
|
@ -27,4 +27,4 @@ Build target for the SSR server.
|
||||
- **Type:** `'esm' | 'cjs'`
|
||||
- **Default:** `esm`
|
||||
|
||||
Build format for the SSR server. Since Vite v3 the SSR build generates ESM by default. `'cjs'` can be selected to generate a CJS build, but it isn't recommended. The option is left marked as experimental to give users more time to update to ESM. CJS builds requires complex externalization heuristics that aren't present in the ESM format.
|
||||
Build format for the SSR server. Since Vite v3 the SSR build generates ESM by default. `'cjs'` can be selected to generate a CJS build, but it isn't recommended. The option is left marked as experimental to give users more time to update to ESM. CJS builds require complex externalization heuristics that aren't present in the ESM format.
|
||||
|
@ -250,7 +250,7 @@ function loadEnv(
|
||||
|
||||
**Related:** [`.env` Files](./env-and-mode.md#env-files)
|
||||
|
||||
Load `.env` files within the `envDir`. By default only env variables prefixed with `VITE_` are loaded, unless `prefixes` is changed.
|
||||
Load `.env` files within the `envDir`. By default, only env variables prefixed with `VITE_` are loaded, unless `prefixes` is changed.
|
||||
|
||||
## `normalizePath`
|
||||
|
||||
@ -277,7 +277,7 @@ async function transformWithEsbuild(
|
||||
): Promise<ESBuildTransformResult>
|
||||
```
|
||||
|
||||
Transform JavaScript or TypeScript with esbuild. Useful for plugins that prefers matching Vite's internal esbuild transform.
|
||||
Transform JavaScript or TypeScript with esbuild. Useful for plugins that prefer matching Vite's internal esbuild transform.
|
||||
|
||||
## `loadConfigFromFile`
|
||||
|
||||
|
@ -54,7 +54,7 @@ export default defineConfig({
|
||||
|
||||
Falsy plugins will be ignored, which can be used to easily activate or deactivate plugins.
|
||||
|
||||
`plugins` also accept presets including several plugins as a single element. This is useful for complex features (like framework integration) that are implemented using several plugins. The array will be flattened internally.
|
||||
`plugins` also accepts presets including several plugins as a single element. This is useful for complex features (like framework integration) that are implemented using several plugins. The array will be flattened internally.
|
||||
|
||||
```js
|
||||
// framework-plugin
|
||||
@ -214,7 +214,7 @@ Vite plugins can also provide hooks that serve Vite-specific purposes. These hoo
|
||||
- **Type:** `(config: ResolvedConfig) => void | Promise<void>`
|
||||
- **Kind:** `async`, `parallel`
|
||||
|
||||
Called after the Vite config is resolved. Use this hook to read and store the final resolved config. It is also useful when the plugin needs to do something different based the command is being run.
|
||||
Called after the Vite config is resolved. Use this hook to read and store the final resolved config. It is also useful when the plugin needs to do something different based on the command being run.
|
||||
|
||||
**Example:**
|
||||
|
||||
|
@ -28,7 +28,7 @@ The behavior is similar to webpack's `file-loader`. The difference is that the i
|
||||
|
||||
### Explicit URL Imports
|
||||
|
||||
Assets that are not included in the internal list or in `assetsInclude`, can be explicitly imported as an URL using the `?url` suffix. This is useful, for example, to import [Houdini Paint Worklets](https://houdini.how/usage).
|
||||
Assets that are not included in the internal list or in `assetsInclude`, can be explicitly imported as a URL using the `?url` suffix. This is useful, for example, to import [Houdini Paint Worklets](https://houdini.how/usage).
|
||||
|
||||
```js
|
||||
import workletURL from 'extra-scalloped-border/worklet.js?url'
|
||||
|
@ -83,7 +83,7 @@ If you need a custom integration, you can follow the steps in this guide to conf
|
||||
- The manifest has a `Record<name, chunk>` structure
|
||||
- For entry or dynamic entry chunks, the key is the relative src path from project root.
|
||||
- For non entry chunks, the key is the base name of the generated file prefixed with `_`.
|
||||
- Chunks will contain information on its static and dynamic imports (both are keys that maps to the corresponding chunk in the manifest), and also its corresponding CSS and asset files (if any).
|
||||
- Chunks will contain information on its static and dynamic imports (both are keys that map to the corresponding chunk in the manifest), and also its corresponding CSS and asset files (if any).
|
||||
|
||||
You can use this file to render links or preload directives with hashed filenames (note: the syntax here is for explanation only, substitute with your server templating language):
|
||||
|
||||
|
@ -60,7 +60,7 @@ export default defineConfig({
|
||||
When making changes to the linked dep, restart the dev server with the `--force` command line option for the changes to take effect.
|
||||
|
||||
::: warning Deduping
|
||||
Due to differences in linked dependency resolution, transitive dependencies can deduplicated incorrectly, causing issues when used in runtime. If you stumble on this issue, use `npm pack` on the linked dependency to fix it.
|
||||
Due to differences in linked dependency resolution, transitive dependencies can deduplicate incorrectly, causing issues when used in runtime. If you stumble on this issue, use `npm pack` on the linked dependency to fix it.
|
||||
:::
|
||||
|
||||
## Customizing the Behavior
|
||||
|
@ -113,7 +113,7 @@ can be removed by passing `build.commonjsOptions: { include: [] }`
|
||||
|
||||
## Advanced
|
||||
|
||||
There are some changes which only affects plugin/tool creators.
|
||||
There are some changes which only affect plugin/tool creators.
|
||||
|
||||
- [[#5868] refactor: remove deprecated api for 3.0](https://github.com/vitejs/vite/pull/5868)
|
||||
- `printHttpServerUrls` is removed
|
||||
|
@ -177,7 +177,7 @@ Then, in `server.js` we need to add some production specific logic by checking `
|
||||
|
||||
- Move the creation and all usage of the `vite` dev server behind dev-only conditional branches, then add static file serving middlewares to serve files from `dist/client`.
|
||||
|
||||
Refer to the [Vue](https://github.com/vitejs/vite/tree/main/playground/ssr-vue) and [React](https://github.com/vitejs/vite/tree/main/playground/ssr-react) demos for working setup.
|
||||
Refer to the [Vue](https://github.com/vitejs/vite/tree/main/playground/ssr-vue) and [React](https://github.com/vitejs/vite/tree/main/playground/ssr-react) demos for a working setup.
|
||||
|
||||
## Generating Preload Directives
|
||||
|
||||
@ -201,7 +201,7 @@ const html = await vueServerRenderer.renderToString(app, ctx)
|
||||
// ctx.modules is now a Set of module IDs that were used during the render
|
||||
```
|
||||
|
||||
In the production branch of `server.js` we need to read and pass the manifest to the `render` function exported by `src/entry-server.js`. This would provide us with enough information to render preload directives for files used by async routes! See [demo source](https://github.com/vitejs/vite/blob/main/playground/ssr-vue/src/entry-server.js) for full example.
|
||||
In the production branch of `server.js` we need to read and pass the manifest to the `render` function exported by `src/entry-server.js`. This would provide us with enough information to render preload directives for files used by async routes! See [demo source](https://github.com/vitejs/vite/blob/main/playground/ssr-vue/src/entry-server.js) for a full example.
|
||||
|
||||
## Pre-Rendering / SSG
|
||||
|
||||
@ -216,12 +216,12 @@ If a dependency needs to be transformed by Vite's pipeline, for example, because
|
||||
For linked dependencies, they are not externalized by default to take advantage of Vite's HMR. If this isn't desired, for example, to test dependencies as if they aren't linked, you can add it to [`ssr.external`](../config/ssr-options.md#ssr-external).
|
||||
|
||||
:::warning Working with Aliases
|
||||
If you have configured aliases that redirects one package to another, you may want to alias the actual `node_modules` packages instead to make it work for SSR externalized dependencies. Both [Yarn](https://classic.yarnpkg.com/en/docs/cli/add/#toc-yarn-add-alias) and [pnpm](https://pnpm.js.org/en/aliases) support aliasing via the `npm:` prefix.
|
||||
If you have configured aliases that redirect one package to another, you may want to alias the actual `node_modules` packages instead to make it work for SSR externalized dependencies. Both [Yarn](https://classic.yarnpkg.com/en/docs/cli/add/#toc-yarn-add-alias) and [pnpm](https://pnpm.js.org/en/aliases) support aliasing via the `npm:` prefix.
|
||||
:::
|
||||
|
||||
## SSR-specific Plugin Logic
|
||||
|
||||
Some frameworks such as Vue or Svelte compiles components into different formats based on client vs. SSR. To support conditional transforms, Vite passes an additional `ssr` property in the `options` object of the following plugin hooks:
|
||||
Some frameworks such as Vue or Svelte compile components into different formats based on client vs. SSR. To support conditional transforms, Vite passes an additional `ssr` property in the `options` object of the following plugin hooks:
|
||||
|
||||
- `resolveId`
|
||||
- `load`
|
||||
@ -269,4 +269,4 @@ Use a post hook so that your SSR middleware runs _after_ Vite's middlewares.
|
||||
|
||||
## SSR Format
|
||||
|
||||
By default, Vite generates the SSR bundle in ESM. There is experimental support for configuring `ssr.format`, but it isn't recommended. Future efforts around SSR development will be based on ESM, and CommonJS remain available for backward compatibility. If using ESM for SSR isn't possible in your project, you can set `legacy.buildSsrCjsExternalHeuristics: true` to generate a CJS bundle using the same [externalization heuristics of Vite v2](https://v2.vitejs.dev/guide/ssr.html#ssr-externals).
|
||||
By default, Vite generates the SSR bundle in ESM. There is experimental support for configuring `ssr.format`, but it isn't recommended. Future efforts around SSR development will be based on ESM, and CommonJS remains available for backward compatibility. If using ESM for SSR isn't possible in your project, you can set `legacy.buildSsrCjsExternalHeuristics: true` to generate a CJS bundle using the same [externalization heuristics of Vite v2](https://v2.vitejs.dev/guide/ssr.html#ssr-externals).
|
||||
|
@ -40,9 +40,9 @@ $ npm run build
|
||||
$ npm run preview
|
||||
```
|
||||
|
||||
The `vite preview` command will boot up local static web server that serves the files from `dist` at `http://localhost:4173`. It's an easy way to check if the production build looks OK in your local environment.
|
||||
The `vite preview` command will boot up a local static web server that serves the files from `dist` at `http://localhost:4173`. It's an easy way to check if the production build looks OK in your local environment.
|
||||
|
||||
You may configure the port of the server by passing `--port` flag as an argument.
|
||||
You may configure the port of the server by passing the `--port` flag as an argument.
|
||||
|
||||
```json
|
||||
{
|
||||
@ -363,6 +363,6 @@ You can deploy your Vite app as a Static Site on [Render](https://render.com/).
|
||||
|
||||
Your app should be deployed at `https://<PROJECTNAME>.onrender.com/`.
|
||||
|
||||
By default, any new commit pushed to the specified branch will automatically trigger a new deploy. [Auto-Deploy](https://render.com/docs/deploys#toggling-auto-deploy-for-a-service) can be configured in the project settings.
|
||||
By default, any new commit pushed to the specified branch will automatically trigger a new deployment. [Auto-Deploy](https://render.com/docs/deploys#toggling-auto-deploy-for-a-service) can be configured in the project settings.
|
||||
|
||||
You can also add a [custom domain](https://render.com/docs/custom-domains) to your project.
|
||||
|
@ -24,7 +24,7 @@ export default defineConfig({
|
||||
})
|
||||
```
|
||||
|
||||
`plugins` also accept presets including several plugins as a single element. This is useful for complex features (like framework integration) that are implemented using several plugins. The array will be flattened internally.
|
||||
`plugins` also accepts presets including several plugins as a single element. This is useful for complex features (like framework integration) that are implemented using several plugins. The array will be flattened internally.
|
||||
|
||||
Falsy plugins will be ignored, which can be used to easily activate or deactivate plugins.
|
||||
|
||||
|
@ -51,7 +51,7 @@ Ensuring optimal output and behavioral consistency between the dev server and th
|
||||
|
||||
## Why Not Bundle with esbuild?
|
||||
|
||||
While `esbuild` is blazing fast and is already a very capable bundler for libraries, some of the important features needed for bundling _applications_ are still work in progress - in particular code-splitting and CSS handling. For the time being, Rollup is more mature and flexible in these regards. That said, we won't rule out the possibility of using `esbuild` for production build when it stabilizes these features in the future.
|
||||
While `esbuild` is blazing fast and is already a very capable bundler for libraries, some of the important features needed for bundling _applications_ are still work in progress - in particular code-splitting and CSS handling. For the time being, Rollup is more mature and flexible in these regards. That said, we won't rule out the possibility of using `esbuild` for production builds when it stabilizes these features in the future.
|
||||
|
||||
## How is Vite Different from X?
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user