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/api/advanced/plugin.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -124,7 +124,7 @@ The project's `configFile` can be accessed in Vite's config: `project.vite.confi
124
124
Notethatthiswillalsoinheritthe`name`-Vitestdoesn't allow multiple projects with the same name, so this will throw an error. Make sure you specified a different name. You can access the current name via the `project.name` property and all used names are available in the `vitest.projects` array.
Vitest creates a persistent file hash based on file content, its id, Vite's environment configuration and coverage status. Vitest tries to use as much information as it has about the configuration, but it is still incomplete. At the moment, it is not possible to track your plugin options because there is no standard interface for it.
34
-
35
-
If you have a plugin that relies on things outside the file content or the public configuration (like reading another file or a folder), it's possible that the cache will get stale. To work around that, you can define a [cache key generator](/api/advanced/plugin#definecachekeygenerator) to specify a dynamic option or to opt out of caching for that module:
// cache this file based on the value of a dynamic variable
52
-
if (sourceCode.includes('myDynamicVar')) {
53
-
returnprocess.env.DYNAMIC_VAR_VALUE
54
-
}
55
-
})
56
-
}
57
-
}
58
-
],
59
-
test: {
60
-
experimental: {
61
-
fsModuleCache:true,
62
-
},
63
-
},
64
-
})
65
-
```
66
-
67
-
If you are a plugin author, consider defining a [cache key generator](/api/advanced/plugin#definecachekeygenerator) in your plugin if it can be registered with different options that affect the transform result.
68
-
69
-
On the other hand, if your plugin should not affect the cache key, you can opt out by setting `api.vitest.experimental.ignoreFsModuleCache` to `true`:
70
-
71
-
```js [vitest.config.js]
72
-
import { defineConfig } from'vitest/config'
73
-
74
-
exportdefaultdefineConfig({
75
-
plugins: [
76
-
{
77
-
name:'vitest-cache',
78
-
api: {
79
-
vitest: {
80
-
experimental: {
81
-
ignoreFsModuleCache:true,
82
-
},
83
-
},
84
-
},
85
-
},
86
-
],
87
-
test: {
88
-
experimental: {
89
-
fsModuleCache:true,
90
-
},
91
-
},
92
-
})
93
-
```
94
-
95
-
Note that you can still define the cache key generator even if the plugin opts out of module caching.
By default, Vitest will try to find the workspace root and store the cache inside the `node_modules` folder. The root is based on your package manager's lockfile (for example, `.package-lock.json`, `.yarn-state.yml`, `.pnpm/lock.yaml` and so on).
105
-
106
-
At the moment, Vitest ignores the [test.cache.dir](/config/cache) or [cacheDir](https://vite.dev/config/shared-options#cachedir) options completely and creates a separate folder.
In watch mode, Vitest caches all transformed files in memory, which makes reruns fast. However, this cache is discarded once the test run finishes. Enabling this option allows Vitest to persist the transformed modules on the file system, so they can be reused across reruns and separate Vitest processes.
13
+
14
+
A single cache directory is shared by every project in the workspace. By default it lives in `node_modules` at the workspace root (so it is naturally invalidated when dependencies are reinstalled); use [`fsModuleCachePath`](/config/fsmodulecachepath) to change its location. You can delete the cache by running [`vitest --clearCache`](/guide/cli#clearcache).
15
+
16
+
::: warning BROWSER SUPPORT
17
+
At the moment, this option does not affect [the browser](/guide/browser/).
18
+
:::
19
+
20
+
You can debug if your modules are cached by running vitest with a `DEBUG=vitest:cache:fs` environment variable:
21
+
22
+
```shell
23
+
DEBUG=vitest:cache:fs vitest --fsModuleCache
24
+
```
25
+
26
+
::: tip
27
+
The location of the cache is a single, workspace-wide directory. See [`fsModuleCachePath`](/config/fsmodulecachepath) to move it.
28
+
:::
29
+
30
+
## Known Issues
31
+
32
+
Vitest creates a persistent file hash based on file content, its id, Vite's environment configuration and coverage status. Vitest tries to use as much information as it has about the configuration, but it is still incomplete. At the moment, it is not possible to track your plugin options because there is no standard interface for it.
33
+
34
+
If you have a plugin that relies on things outside the file content or the public configuration (like reading another file or a folder), it's possible that the cache will get stale. To work around that, you can define a [cache key generator](/api/advanced/plugin#definecachekeygenerator) to specify a dynamic option or to opt out of caching for that module:
35
+
36
+
```js [vitest.config.js]
37
+
import { defineConfig } from'vitest/config'
38
+
39
+
exportdefaultdefineConfig({
40
+
plugins: [
41
+
{
42
+
name:'vitest-cache',
43
+
configureVitest({ defineCacheKeyGenerator }) {
44
+
defineCacheKeyGenerator(({ id, sourceCode }) => {
45
+
// never cache this id
46
+
if (id.includes('do-not-cache')) {
47
+
returnfalse
48
+
}
49
+
50
+
// cache this file based on the value of a dynamic variable
51
+
if (sourceCode.includes('myDynamicVar')) {
52
+
returnprocess.env.DYNAMIC_VAR_VALUE
53
+
}
54
+
})
55
+
}
56
+
}
57
+
],
58
+
test: {
59
+
fsModuleCache:true,
60
+
},
61
+
})
62
+
```
63
+
64
+
If you are a plugin author, consider defining a [cache key generator](/api/advanced/plugin#definecachekeygenerator) in your plugin if it can be registered with different options that affect the transform result.
65
+
66
+
On the other hand, if your plugin should not affect the cache key, you can opt out by setting `api.vitest.ignoreFsModuleCache` to `true`:
67
+
68
+
```js [vitest.config.js]
69
+
import { defineConfig } from'vitest/config'
70
+
71
+
exportdefaultdefineConfig({
72
+
plugins: [
73
+
{
74
+
name:'vitest-cache',
75
+
api: {
76
+
vitest: {
77
+
ignoreFsModuleCache:true,
78
+
},
79
+
},
80
+
},
81
+
],
82
+
test: {
83
+
fsModuleCache:true,
84
+
},
85
+
})
86
+
```
87
+
88
+
Note that you can still define the cache key generator even if the plugin opts out of module caching.
-**Default:**`'node_modules/.vitest-cache'` (resolved from the workspace root)
10
+
-**CLI:**`--fsModuleCachePath=<path>`
11
+
12
+
Directory where the [`fsModuleCache`](/config/fsmodulecache) is stored.
13
+
14
+
This can be set per project; projects that don't override it fall back to the root's cache directory. The lockfile metadata used to invalidate the cache is always shared across the whole workspace.
15
+
16
+
By default Vitest stores the cache inside `node_modules` at the workspace root. The root is based on your package manager's lockfile (for example, `.package-lock.json`, `.yarn-state.yml`, `.pnpm/lock.yaml` and so on). Keeping it inside `node_modules` means the cache is naturally invalidated whenever dependencies are reinstalled.
Directory where the `fsModuleCache` is stored (default: `node_modules/.vitest-cache`)
835
+
822
836
### expect.requireAssertions
823
837
824
838
-**CLI:**`--expect.requireAssertions`
@@ -901,7 +915,7 @@ List all available tags instead of running tests. `--list-tags=json` will output
901
915
902
916
-**CLI:**`--clearCache`
903
917
904
-
Delete all Vitest caches, including `experimental.fsModuleCache`, without running any tests. This will reduce the performance in the subsequent test run.
918
+
Delete all Vitest caches, including the `fsModuleCache`, without running any tests. This will reduce the performance in the subsequent test run.
905
919
906
920
### tagsFilter
907
921
@@ -916,13 +930,6 @@ Run only tests with the specified tags. You can use logical operators `&&` (and)
916
930
917
931
Should Vitest throw an error if test has a tag that is not defined in the config. (default: `true`)
Copy file name to clipboardExpand all lines: docs/guide/improving-performance.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -79,7 +79,7 @@ You can limit the working directory when Vitest searches for files using [`test.
79
79
80
80
## Caching Between Reruns
81
81
82
-
In watch mode, Vitest caches all transformed files in memory, which makes reruns fast. However, this cache is discarded once the test run finishes. By enabling [`experimental.fsModuleCache`](/config/experimental#experimental-fsmodulecache), Vitest persists this cache to the file system so it can be reused across reruns.
82
+
In watch mode, Vitest caches all transformed files in memory, which makes reruns fast. However, this cache is discarded once the test run finishes. By enabling [`fsModuleCache`](/config/fsmodulecache), Vitest persists this cache to the file system so it can be reused across reruns.
83
83
84
84
This improvement is most noticeable when rerunning a small number of tests that depend on a large module graph. For full test suites, parallelization already mitigates the cost because other tests populate the in-memory cache while earlier tests are still running. For example, running one test file with a huge module graph (>900 modules):
Copy file name to clipboardExpand all lines: docs/guide/ui.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -118,7 +118,7 @@ By left-clicking on the module node, you open the Module Info view.
118
118
<img alt="The module info view for an inlined module" img-light src="/ui/light-module-info.png">
119
119
<img alt="The module info view for an inlined module" img-dark src="/ui/dark-module-info.png">
120
120
121
-
This view is separated into two parts. The top part shows the full module ID and some diagnostics about the module. If [`experimental.fsModuleCache`](/config/experimental#experimental-fsmodulecache) is enabled, there will be a "cached" or "not cached" badge. On the right you can see time diagnostics:
121
+
This view is separated into two parts. The top part shows the full module ID and some diagnostics about the module. If [`fsModuleCache`](/config/fsmodulecache) is enabled, there will be a "cached" or "not cached" badge. On the right you can see time diagnostics:
122
122
123
123
- Self Time: the time it took to import the module, excluding static imports.
124
124
- Total Time: the time it took to import the module, including static imports. Note that this does not include `transform` time of the current module.
0 commit comments