Merge branch 'main' into build-watch

.github/workflows/ci.yml

@@ -36,7 +36,7 @@ jobs:
     name: "Build&Test: node-${{ matrix.node_version }}, ${{ matrix.os }}"
     steps:
       - name: Checkout
-        uses: actions/checkout@v2
+        uses: actions/checkout@v3
 
       - name: Install pnpm
         uses: pnpm/action-setup@v2
@@ -72,7 +72,7 @@ jobs:
     runs-on: ubuntu-latest
     name: "Lint: node-16, ubuntu-latest"
     steps:
-      - uses: actions/checkout@v2
+      - uses: actions/checkout@v3
         with:
           fetch-depth: 0
 

.github/workflows/lock-closed-issues.yml

@@ -11,11 +11,11 @@ jobs:
   action:
     runs-on: ubuntu-latest
     steps:
-      - uses: dessant/lock-threads@v2
+      - uses: dessant/lock-threads@v3
         with:
           github-token: ${{ secrets.GITHUB_TOKEN }}
-          issue-lock-inactive-days: "14"
-          #issue-lock-comment: |
+          issue-inactive-days: "14"
+          #issue-comment: |
           #  This issue has been locked since it has been closed for more than 14 days.
           #
           #  If you have found a concrete bug or regression related to it, please open a new [bug report](https://github.com/vitejs/vite/issues/new/choose) with a reproduction against the latest Vite version. If you have any other comments you should join the chat at [Vite Land](https://chat.vitejs.dev) or create a new [discussion](https://github.com/vitejs/vite/discussions).

.github/workflows/publish.yml

@@ -15,7 +15,7 @@ jobs:
     environment: Release
     steps:
       - name: Checkout
-        uses: actions/checkout@v2
+        uses: actions/checkout@v3
 
       - name: Install pnpm
         uses: pnpm/action-setup@v2

.github/workflows/release-tag.yml

@@ -13,7 +13,7 @@ jobs:
   release:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v2
+      - uses: actions/checkout@v3
 
       - name: Get pkgName for tag
         id: tag

CONTRIBUTING.md

@@ -10,7 +10,9 @@ To develop and test the core `vite` package:
 
 1. Run `pnpm i` in Vite's root folder
 
-2. Go to `packages/vite` and run `pnpm run dev`. This starts `rollup` in watch mode.
+2. Run `pnpm run build` in Vite's root folder.
+
+3. If you are developing Vite itself, you can go to `packages/vite` and run `pnpm run dev` to automatically rebuild Vite whenever you change its code.
 
 You can alternatively use [Vite.js Docker Dev](https://github.com/nystudio107/vitejs-docker-dev) for a containerized Docker setup for Vite.js development.
 
@@ -67,7 +69,7 @@ And re-run `pnpm install` to link the package.
 
 Each package under `packages/playground/` contains a `__tests__` directory. The tests are run using [Jest](https://jestjs.io/) + [Playwright](https://playwright.dev/) with custom integrations to make writing tests simple. The detailed setup is inside `jest.config.js` and `scripts/jest*` files.
 
-Each test can be run under either dev server mode or build mode.
+Each test can be run under either dev server mode or build mode. Make sure that [Vite has been built](#repo-setup).
 
 - `pnpm test` by default runs every test in both serve and build mode.
 

docs/config/index.md

@@ -27,14 +27,17 @@ You can also explicitly specify a config file to use with the `--config` CLI opt
 vite --config my-config.js
 ```
 
-Note that Vite will replace `__filename`, `__dirname`, and `import.meta.url`. Using these as variable names will result in an error:
+::: tip NOTE
+Vite will replace `__filename`, `__dirname`, and `import.meta.url` in **CommonJS** and **TypeScript** config files. Using these as variable names will result in an error:
 
 ```js
 const __filename = "value"
 // will be transformed to
 const "path/vite.config.js" = "value"
 ```
 
+:::
+
 ### Config Intellisense
 
 Since Vite ships with TypeScript typings, you can leverage your IDE's intellisense with jsdoc type hints:
@@ -96,6 +99,22 @@ export default defineConfig(async ({ command, mode }) => {
 })
 ```
 
+### Environment Variables
+
+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.
+
+```js
+import { defineConfig, loadEnv } from 'vite'
+
+export default defineConfig(({ command, mode }) => {
+  // Load env file based on `mode` in the current working directory
+  const env = loadEnv(mode, process.cwd())
+  return {
+    // build specific config
+  }
+})
+```
+
 ## Shared Options
 
 ### root
@@ -139,9 +158,11 @@ export default defineConfig(async ({ command, mode }) => {
 
   - Replacements are performed only when the match is surrounded by word boundaries (`\b`).
 
+  ::: warning
   Because it's implemented as straightforward text replacements without any syntax analysis, we recommend using `define` for CONSTANTS only.
 
   For example, `process.env.FOO` and `__APP_VERSION__` are good fits. But `process` or `global` should not be put into this option. Variables can be shimmed or polyfilled instead.
+  :::
 
   ::: tip NOTE
   For TypeScript users, make sure to add the type declarations in the `env.d.ts` or `vite-env.d.ts` file to get type checks and Intellisense.
@@ -223,6 +244,10 @@ export default defineConfig(async ({ command, mode }) => {
 
   Vite has a list of "allowed conditions" and will match the first condition that is in the allowed list. The default allowed conditions are: `import`, `module`, `browser`, `default`, and `production/development` based on current mode. The `resolve.conditions` config option allows specifying additional allowed conditions.
 
+  :::warning Resolving subpath exports
+  Export keys ending with "/" is deprecated by Node and may not work well. Please contact the package author to use [`*` subpath patterns](https://nodejs.org/api/packages.html#package-entry-points) instead.
+  :::
+
 ### resolve.mainFields
 
 - **Type:** `string[]`
@@ -277,22 +302,25 @@ export default defineConfig(async ({ command, mode }) => {
 
 - **Type:** `string | (postcss.ProcessOptions & { plugins?: postcss.Plugin[] })`
 
-  Inline PostCSS config (expects the same format as `postcss.config.js`), or a custom path to search PostCSS config from (default is project root). The search is done using [postcss-load-config](https://github.com/postcss/postcss-load-config).
+  Inline PostCSS config (expects the same format as `postcss.config.js`), or a custom directory to search PostCSS config from (default is project root). The search is done using [postcss-load-config](https://github.com/postcss/postcss-load-config) and only the supported config file names are loaded.
 
   Note if an inline config is provided, Vite will not search for other PostCSS config sources.
 
 ### css.preprocessorOptions
 
 - **Type:** `Record<string, object>`
 
-  Specify options to pass to CSS pre-processors. Example:
+  Specify options to pass to CSS pre-processors. The file extensions are used as keys for the options. Example:
 
   ```js
   export default defineConfig({
     css: {
       preprocessorOptions: {
         scss: {
           additionalData: `$injectedColor: orange;`
+        },
+        styl: {
+          additionalData: `$injectedColor ?= orange`
         }
       }
     }
@@ -330,7 +358,7 @@ export default defineConfig(async ({ command, mode }) => {
   })
   ```
 
-  By default, ESBuild is applied to `ts`, `jsx` and `tsx` files. You can customize this with `esbuild.include` and `esbuild.exclude`, both of which expect type of `string | RegExp | (string | RegExp)[]`.
+  By default, ESBuild is applied to `ts`, `jsx` and `tsx` files. You can customize this with `esbuild.include` and `esbuild.exclude`, which can be a regex, a [picomatch](https://github.com/micromatch/picomatch#globbing-features) pattern, or an array of either.
 
   In addition, you can also use `esbuild.jsxInject` to automatically inject JSX helper imports for every file transformed by ESBuild:
 
@@ -349,7 +377,7 @@ export default defineConfig(async ({ command, mode }) => {
 - **Type:** `string | RegExp | (string | RegExp)[]`
 - **Related:** [Static Asset Handling](/guide/assets)
 
-  Specify additional [picomatch patterns](https://github.com/micromatch/picomatch) to be treated as static assets so that:
+  Specify additional [picomatch patterns](https://github.com/micromatch/picomatch#globbing-features) to be treated as static assets so that:
 
   - They will be excluded from the plugin transform pipeline when referenced from HTML or directly requested over `fetch` or XHR.
 
@@ -499,6 +527,12 @@ export default defineConfig(async ({ command, mode }) => {
 
   Configure CORS for the dev server. This is enabled by default and allows any origin. Pass an [options object](https://github.com/expressjs/cors) to fine tune the behavior or `false` to disable.
 
+### server.headers
+
+- **Type:** `OutgoingHttpHeaders`
+
+  Specify server response headers.
+
 ### server.force
 
 - **Type:** `boolean`
@@ -518,7 +552,7 @@ export default defineConfig(async ({ command, mode }) => {
 
   `clientPort` is an advanced option that overrides the port only on the client side, allowing you to serve the websocket on a different port than the client code looks for it on. Useful if you're using an SSL proxy in front of your dev server.
 
-  When using `server.middlewareMode` or `server.https`, assigning `server.hmr.server` to your HTTP(S) server will process HMR connection requests through your server. This can be helpful when using self-signed certificates or when you want to expose Vite over a network on a single port.
+  If specifying `server.hmr.server`, Vite will process HMR connection requests through the provided server. If not in middleware mode, Vite will attempt to process HMR connection requests through the existing server. This can be helpful when using self-signed certificates or when you want to expose Vite over a network on a single port.
 
 ### server.watch
 
@@ -582,6 +616,12 @@ async function createServer() {
 createServer()
 ```
 
+### server.base
+
+- **Type:** `string | undefined`
+
+  Prepend this folder to http requests, for use when proxying vite as a subfolder. Should start and end with the `/` character.
+
 ### server.fs.strict
 
 - **Type:** `boolean`

docs/guide/api-plugin.md

@@ -458,7 +458,7 @@ In general, as long as a Rollup plugin fits the following criteria then it shoul
 - It doesn't use the [`moduleParsed`](https://rollupjs.org/guide/en/#moduleparsed) hook.
 - It doesn't have strong coupling between bundle-phase hooks and output-phase hooks.
 
-If a Rollup plugin only makes sense for the build phase, then it can be specified under `build.rollupOptions.plugins` instead.
+If a Rollup plugin only makes sense for the build phase, then it can be specified under `build.rollupOptions.plugins` instead. It will work the same as a Vite plugin with `enforce: 'post'` and `apply: 'build'`.
 
 You can also augment an existing Rollup plugin with Vite-only properties:
 

docs/guide/backend-integration.md

@@ -33,7 +33,6 @@ If you need a custom integration, you can follow the steps in this guide to conf
 
    ```html
    <!-- if development -->
-   <script type="module" src="http://localhost:3000/@vite/client"></script>
    <script type="module" src="http://localhost:3000/main.js"></script>
    ```
 

docs/guide/build.md

@@ -43,6 +43,20 @@ module.exports = defineConfig({
 
 For example, you can specify multiple Rollup outputs with plugins that are only applied during build.
 
+## Chunking Strategy
+
+You can configure how chunks are split using `build.rollupOptions.output.manualChunks` (see [Rollup docs](https://rollupjs.org/guide/en/#outputmanualchunks)). Until Vite 2.8, the default chunking strategy divided the chunks into `index` and `vendor`. It is a good strategy for some SPAs, but it is hard to provide a general solution for every Vite target use case. From Vite 2.9, `manualChunks` is no longer modified by default. You can continue to use the Split Vendor Chunk strategy by adding the `splitVendorChunkPlugin` in your config file:
+
+```js
+// vite.config.js
+import { splitVendorChunkPlugin } from 'vite'
+module.exports = defineConfig({
+  plugins: [splitVendorChunkPlugin()]
+})
+```
+
+This strategy is also provided as a `splitVendorChunk({ cache: SplitVendorChunkCache })` factory, in case composition with custom logic is needed. `cache.reset()` needs to be called at `buildStart` for build watch mode to work correctly in this case.
+
 ## Rebuild on files changes
 
 You can enable rollup watcher with `vite build --watch`. Or, you can directly adjust the underlying [`WatcherOptions`](https://rollupjs.org/guide/en/#watch-options) via `build.watch`:
@@ -58,6 +72,8 @@ module.exports = defineConfig({
 })
 ```
 
+With the `--watch` flag enabled, changes to the `vite.config.js`, as well as any files to be bundled, will trigger a rebuild.
+
 ## Multi-Page App
 
 Suppose you have the following source code structure:
@@ -129,6 +145,15 @@ module.exports = defineConfig({
 })
 ```
 
+The entry file would contain exports that can be imported by users of your package:
+
+```js
+// lib/main.js
+import Foo from './Foo.vue'
+import Bar from './Bar.vue'
+export { Foo, Bar }
+```
+
 Running `vite build` with this config uses a Rollup preset that is oriented towards shipping libraries and produces two bundle formats: `es` and `umd` (configurable via `build.lib`):
 
 ```

docs/guide/dep-pre-bundling.md

@@ -28,7 +28,9 @@ This is Vite performing what we call "dependency pre-bundling". This process ser
 
    By pre-bundling `lodash-es` into a single module, we now only need one HTTP request instead!
 
-Note that this only applies in development mode.
+::: tip NOTE
+Dependency pre-bundling only applies in development mode, and uses `esbuild` to convert dependencies to ESM. In production builds, `@rollup/plugin-commonjs` is used instead.
+:::
 
 ## Automatic Dependency Discovery
 

docs/guide/features.md

@@ -298,10 +298,10 @@ const modules = {
 }
 ```
 
-`import.meta.glob` and `import.meta.globEager` also support importing files as strings, similar to [Importing Asset as String](https://vitejs.dev/guide/assets.html#importing-asset-as-string). Here, we use the [Import Assertions](https://github.com/tc39/proposal-import-assertions#synopsis) syntax to import.
+`import.meta.glob` and `import.meta.globEager` also support importing files as strings (similar to [Importing Asset as String](https://vitejs.dev/guide/assets.html#importing-asset-as-string)) with the [Import Reflection](https://github.com/tc39/proposal-import-reflection) syntax:
 
 ```js
-const modules = import.meta.glob('./dir/*.js', { assert: { type: 'raw' } })
+const modules = import.meta.glob('./dir/*.js', { as: 'raw' })
 ```
 
 The above will be transformed into the following:
@@ -317,7 +317,7 @@ const modules = {
 Note that:
 
 - This is a Vite-only feature and is not a web or ES standard.
-- The glob patterns are treated like import specifiers: they must be either relative (start with `./`) or absolute (start with `/`, resolved relative to project root).
+- The glob patterns are treated like import specifiers: they must be either relative (start with `./`) or absolute (start with `/`, resolved relative to project root) or an alias path (see [`resolve.alias` option](/config/#resolve-alias)).
 - The glob matching is done via `fast-glob` - check out its documentation for [supported glob patterns](https://github.com/mrmlnc/fast-glob#pattern-syntax).
 - You should also be aware that glob imports do not accept variables, you need to directly pass the string pattern.
 - The glob patterns cannot contain the same quote string (i.e. `'`, `"`, `` ` ``) as outer quotes, e.g. `'/Tom\'s files/**'`, use `"/Tom's files/**"` instead.

package.json

@@ -34,30 +34,30 @@
     "ci-docs": "run-s build-vite build-plugin-vue build-docs"
   },
   "devDependencies": {
-    "@microsoft/api-extractor": "^7.19.4",
+    "@microsoft/api-extractor": "^7.19.5",
     "@types/fs-extra": "^9.0.13",
-    "@types/jest": "^27.4.0",
-    "@types/node": "^16.11.22",
+    "@types/jest": "^27.4.1",
+    "@types/node": "^16.11.26",
     "@types/prompts": "^2.0.14",
     "@types/semver": "^7.3.9",
-    "@typescript-eslint/eslint-plugin": "^5.11.0",
-    "@typescript-eslint/parser": "^5.11.0",
+    "@typescript-eslint/eslint-plugin": "^5.16.0",
+    "@typescript-eslint/parser": "^5.16.0",
     "conventional-changelog-cli": "^2.2.2",
     "cross-env": "^7.0.3",
-    "esbuild": "^0.14.14",
-    "eslint": "^8.8.0",
-    "eslint-define-config": "^1.2.4",
+    "esbuild": "^0.14.27",
+    "eslint": "^8.11.0",
+    "eslint-define-config": "^1.3.0",
     "eslint-plugin-node": "^11.1.0",
     "execa": "^5.1.1",
-    "fs-extra": "^10.0.0",
+    "fs-extra": "^10.0.1",
     "jest": "^27.5.1",
-    "lint-staged": "^12.3.3",
+    "lint-staged": "^12.3.7",
     "minimist": "^1.2.5",
     "node-fetch": "^2.6.6",
     "npm-run-all": "^4.1.5",
     "picocolors": "^1.0.0",
-    "playwright-chromium": "^1.18.1",
-    "prettier": "2.5.1",
+    "playwright-chromium": "^1.20.0",
+    "prettier": "2.6.0",
     "prompts": "^2.4.2",
     "rimraf": "^3.0.2",
     "rollup": "^2.59.0",
@@ -68,7 +68,7 @@
     "ts-node": "^10.4.0",
     "typescript": "~4.5.4",
     "vite": "workspace:*",
-    "vitepress": "^0.21.6"
+    "vitepress": "^0.22.3"
   },
   "simple-git-hooks": {
     "pre-commit": "pnpm exec lint-staged --concurrent false",
@@ -85,7 +85,7 @@
       "eslint --ext .ts"
     ]
   },
-  "packageManager": "pnpm@6.30.0",
+  "packageManager": "pnpm@6.32.3",
   "pnpm": {
     "overrides": {
       "vite": "workspace:*",

packages/create-vite/template-vue-ts/README.md

@@ -8,4 +8,9 @@ This template should help get you started developing with Vue 3 and Typescript i
 
 ## Type Support For `.vue` Imports in TS
 
-Since TypeScript cannot handle type information for `.vue` imports, they are shimmed to be a generic Vue component type by default. In most cases this is fine if you don't really care about component prop types outside of templates. However, if you wish to get actual prop types in `.vue` imports (for example to get props validation when using manual `h(...)` calls), you can enable Volar's `.vue` type support plugin by running `Volar: Switch TS Plugin on/off` from VSCode command palette.
+Since TypeScript cannot handle type information for `.vue` imports, they are shimmed to be a generic Vue component type by default. In most cases this is fine if you don't really care about component prop types outside of templates. However, if you wish to get actual prop types in `.vue` imports (for example to get props validation when using manual `h(...)` calls), you can enable Volar's Take Over mode by following these steps:
+
+1. Run `Extensions: Show Built-in Extensions` from VSCode's command palette, look for `TypeScript and JavaScript Language Features`, then right click and select `Disable (Workspace)`. By default, Take Over mode will enable itself if the default TypeScript extension is disabled.
+2. Reload the VSCode window by running `Developer: Reload Window` from the command palette.
+
+You can learn more about Take Over mode [here](https://github.com/johnsoncodehk/volar/discussions/471).

packages/create-vite/template-vue-ts/tsconfig.json

@@ -8,6 +8,7 @@
     "jsx": "preserve",
     "sourceMap": true,
     "resolveJsonModule": true,
+    "isolatedModules": true,
     "esModuleInterop": true,
     "lib": ["esnext", "dom"]
   },