[READ-ONLY] Mirror of https://github.com/vitest-dev/vitest. Next generation testing framework powered by Vite. vitest.dev
test testing-tools vite
12

Configure Feed

Select the types of activity you want to include in your feed.

docs: update workspace docs (#3157)

authored by

Anjorin Damilare and committed by
GitHub
(Apr 12, 2023, 9:07 PM +0200) b81ffd90 aa22f797

+7 -7
+2 -2
docs/config/index.md
··· 75 75 ::: 76 76 77 77 ::: tip 78 - All configuration options that are not supported inside a [workspace](/guide/workspace) project config have <NonProjectOption /> sign next them. 78 + All configuration options that are not supported inside a [workspace](/guide/workspace) project config have <NonProjectOption /> sign next to them. 79 79 ::: 80 80 81 81 ### include ··· 105 105 - **See also:** [Dep Optimization Options](https://vitejs.dev/config/dep-optimization-options.html) 106 106 107 107 ::: warning 108 - This feature is temporary disabled since Vitest 0.30.0. 108 + This feature is temporarily disabled since Vitest 0.30.0. 109 109 ::: 110 110 111 111 Enable dependency optimization. If you have a lot of tests, this might improve their performance.
+1 -1
docs/guide/index.md
··· 63 63 64 64 ## Workspaces Support 65 65 66 - Run different project configurations inside the same project with [Vitest Workspaces](/guide/workspace). You can define a list of files and folders that define you workspace in `vitest.workspace` file. The file supports `js`/`ts`/`json` extensions. This feature works great with monorepo setups. 66 + Run different project configurations inside the same project with [Vitest Workspaces](/guide/workspace). You can define a list of files and folders that define your workspace in `vitest.workspace` file. The file supports `js`/`ts`/`json` extensions. This feature works great with monorepo setups. 67 67 68 68 ```ts 69 69 import { defineWorkspace } from 'vitest/config'
+4 -4
docs/guide/workspace.md
··· 4 4 5 5 ## Defining a workspace 6 6 7 - A workspace should have a `vitest.workspace` or `vitest.projects` file in its root (in the same folder with your config file, if you have one). Vitest supports `ts`/`js`/`json` extensions for this file. 7 + 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. 8 8 9 9 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 with your projects named `packages`, you can define a workspace with this config file: 10 10 ··· 69 69 ::: 70 70 71 71 ::: warning 72 - All projects should have unique names. Otherwise Vitest will throw an error. If you do not provide a name inside 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. 72 + 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. 73 73 ::: 74 74 75 75 If you don't rely on inline configs, you can just create a small json file in your root directory: ··· 119 119 ``` 120 120 ::: 121 121 122 - Also some of the configuration options are not allowed in a project config. Most notably: 122 + Also, some of the configuration options are not allowed in a project config. Most notably: 123 123 124 124 - `coverage`: coverage is done for the whole workspace 125 125 - `reporters`: only root-level reporters can be supported ··· 132 132 133 133 ## Coverage 134 134 135 - Coverage for workspace projects works out of the box. But if you have [`all`](/config/#coverage-all) option enabled and use non-conventional extensions in some of you projects, you will need to have a plugin that handles this extension in your root configuration file. 135 + Coverage for workspace projects works out of the box. But if you have [`all`](/config/#coverage-all) option enabled and use non-conventional extensions in some of your projects, you will need to have a plugin that handles this extension in your root configuration file. 136 136 137 137 For example, if you have a package that uses Vue files and it has its own config file, but some of the files are not imported in your tests, coverage will fail trying to analyze the usage of unused files, because it relies on the root configuration rather than project configuration.