feat: promote fsModuleCache to a top-level option - #10734
Conversation
✅ Deploy Preview for vitest-dev ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
c6f19ee to
7283040
Compare
Move `fsModuleCache` and `fsModuleCachePath` out of `experimental` (`fsModuleCache` defaults to off) and stabilize the plugin API: the `defineCacheKeyGenerator` hook and the `api.vitest.ignoreFsModuleCache` opt-out. `fsModuleCachePath` can be set per project, falling back to the root's cache directory (`node_modules/.vitest-cache` by default), while the lockfile metadata stays shared across the workspace. The deprecated `experimental.*` options, `experimental_defineCacheKeyGenerator` and `api.vitest.experimental.ignoreFsModuleCache` keep working with a deprecation notice. Fixes #10701
7283040 to
df25a89
Compare
|
Should we enable it by default only in non-CI environments? There is usually a performance hit for the first (cold) run and in CI there is usually no caching anyway |
| On the other hand, if your plugin should not affect the cache key, you can opt out by setting `api.vitest.ignoreFsModuleCache` to `true`: | ||
|
|
||
| ```js [vitest.config.js] | ||
| import { defineConfig } from 'vitest/config' | ||
|
|
||
| export default defineConfig({ | ||
| plugins: [ | ||
| { | ||
| name: 'vitest-cache', | ||
| api: { | ||
| vitest: { | ||
| ignoreFsModuleCache: true, |
There was a problem hiding this comment.
I don't remember the use case of per plugin ignoreFsModuleCache. From what I can imagine, this only basically plugin's existence to not affect cache key, so it's like adding/removing the plugin conditionally for different test run:
plugins: [
process.env.SOME_CONDITION && {
...some logic...
api: { vitest: { ignoreFsModuleCache: true }}
}
]Is this the right use case? The option name ignoreFsModuleCache and documentation here doesn't seem to give much intuition. Not mean to bike-shed now and no blocking though.
There was a problem hiding this comment.
Yes, kind of. It will be ignored when generating a cache key. This is mostly useful for library authors or when calling vitest programmatically (we even pass down this flag ourselves in a fee places). For config it doesn’t make much sense because config content (its file content - the string) affects the cache key.
This is for plugins that don’t affect transformation. If you move the order, it also won’t affect it for example.
Move
fsModuleCacheandfsModuleCachePathout ofexperimental(fsModuleCachedefaults to off). The cache is a single workspace-rootnode_modules/.vitest-cachedirectory shared by every project. The oldexperimental.*options are migrated with a deprecation warning.Fixes #10701