You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/guide/workspace.md
+18-17Lines changed: 18 additions & 17 deletions
Original file line number
Diff line number
Diff line change
@@ -14,9 +14,13 @@ Vitest provides built-in support for monorepos through a workspace configuration
14
14
15
15
## Defining a Workspace
16
16
17
-
A workspace should have a `vitest.workspace` or `vitest.projects` file in its root (in the same folder as your config file if you have one). Vitest supports `ts`/`js`/`json` extensions for this file.
17
+
A workspace must include a `vitest.workspace` or `vitest.projects` file in its root directory (located in the same folder as your root configuration file, if applicable). Vitest supports `ts`, `js`, and `json` extensions for this file.
18
18
19
-
Workspace configuration file should have a default export with a list of files or glob patterns referencing your projects. For example, if you have a folder named `packages` that contains your projects, you can define a workspace with this config file:
19
+
::: tip NAMING
20
+
Please note that this feature is named `workspace`, not `workspaces` (without an "s" at the end).
21
+
:::
22
+
23
+
Workspace configuration file must have a default export with a list of files or glob patterns referencing your projects. For example, if you have a folder named `packages` that contains your projects, you can define a workspace with this config file:
20
24
21
25
:::code-group
22
26
```ts [vitest.workspace.ts]
@@ -26,10 +30,10 @@ export default [
26
30
```
27
31
:::
28
32
29
-
Vitest will consider every folder in `packages` as a separate project even if it doesn't have a config file inside. Since Vitest 2.1, if this glob pattern matches any file it will be considered a Vitest config even if it doesn't have a `vitest` in its name.
33
+
Vitest will treat every folder in `packages` as a separate project even if it doesn't have a config file inside. Since Vitest 2.1, if this glob pattern matches any file it will be considered a Vitest config even if it doesn't have a `vitest` in its name.
30
34
31
35
::: warning
32
-
Vitest will not consider the root configas a workspace project (so it will not run tests specified in `include`) unless it is specified in this config.
36
+
Vitest does not treat the root `vitest.config` file as a workspace project unless it is explicitly specified in the workspace configuration. Consequently, the root configuration will only influence global options such as `reporters` and `coverage`.
33
37
:::
34
38
35
39
You can also reference projects with their config files:
@@ -42,9 +46,9 @@ export default [
42
46
```
43
47
:::
44
48
45
-
This pattern will only include projects with `vitest.config` file that includes`e2e`and`unit` before the extension.
49
+
This pattern will only include projects with a `vitest.config` file that contains`e2e`or`unit` before the extension.
46
50
47
-
You can also define projects with inline config. Workspace file supports using both syntaxes at the same time.
51
+
You can also define projects using inline configuration. The workspace file supports both syntaxes simultaneously.
All projects should have unique names. Otherwise, Vitest will throw an error. If you do not provide a name inside the inline config, Vitest will assign a number. If you don't provide a name inside a project config defined with glob syntax, Vitest will use the directory name by default.
83
+
All projects must have unique names; otherwise, Vitest will throw an error. If a name is not provided in the inline configuration, Vitest will assign a number. For project configurations defined with glob syntax, Vitest will default to using the "name" property in the nearest `package.json` file or the folder name if no such file exists.
80
84
:::
81
85
82
-
If you don't rely on inline configs, you can just create a small json file in your root directory:
86
+
If you do not use inline configurations, you can create a small JSON file in your root directory:
83
87
84
88
:::code-group
85
89
```json [vitest.workspace.json]
@@ -89,7 +93,7 @@ If you don't rely on inline configs, you can just create a small json file in yo
89
93
```
90
94
:::
91
95
92
-
Workspace projects don't support all configuration properties. For better type safety, use `defineProject` instead of `defineConfig`method inside project configuration files:
96
+
Workspace projects do not support all configuration properties. For better type safety, use the `defineProject`method instead of `defineConfig`within project configuration files:
93
97
94
98
:::code-group
95
99
```ts [packages/a/vitest.config.ts] twoslash
@@ -191,9 +195,10 @@ export default mergeConfig(
191
195
```
192
196
:::
193
197
194
-
At the `defineWorkspace` level you can also use the `extends` option instead to inherit from your root-level config.
198
+
At the `defineWorkspace` level, you can use the `extends` option to inherit from your root-level configuration. All options will be merged.
Also, some of the configuration options are not allowed in a project config. Most notably:
223
+
Some of the configuration options are not allowed in a project config. Most notably:
219
224
220
225
-`coverage`: coverage is done for the whole workspace
221
226
-`reporters`: only root-level reporters can be supported
222
227
-`resolveSnapshotPath`: only root-level resolver is respected
223
228
- all other options that don't affect test runners
224
229
225
230
::: tip
226
-
All configuration options that are not supported inside a project config have <NonProjectOption /> sign next them in ["Config"](/config/)page.
231
+
All configuration options that are not supported inside a project configuration are marked with a <NonProjectOption /> sign in the ["Config"](/config/)guide.
227
232
:::
228
-
229
-
## Coverage
230
-
231
-
Coverage for workspace projects works out of the box.
0 commit comments