perf(experimental): add file system cache

[sheremet-va]

Description

This PR adds a file system module cache that can be enabled via experimental.fsModuleCache.

Having a file system cache makes it faster to rerun tests on big projects.

Fixes #6441

Some numbers with FS Cache (4.0.11):

first run

   Duration  8.75s (transform 4.02s, setup 629ms, collect 5.52s, tests 2.52s, environment 0ms, prepare 3ms)

vs second run

   Duration  5.90s (transform 842ms, setup 543ms, collect 2.35s, tests 2.94s, environment 0ms, prepare 3ms)

[pkg-pr-new]

@vitest/browser

npm i https://pkg.pr.new/@vitest/browser@9026

@vitest/browser-playwright

npm i https://pkg.pr.new/@vitest/browser-playwright@9026

@vitest/browser-preview

npm i https://pkg.pr.new/@vitest/browser-preview@9026

@vitest/browser-webdriverio

npm i https://pkg.pr.new/@vitest/browser-webdriverio@9026

@vitest/coverage-istanbul

npm i https://pkg.pr.new/@vitest/coverage-istanbul@9026

@vitest/coverage-v8

npm i https://pkg.pr.new/@vitest/coverage-v8@9026

@vitest/expect

npm i https://pkg.pr.new/@vitest/expect@9026

@vitest/mocker

npm i https://pkg.pr.new/@vitest/mocker@9026

@vitest/pretty-format

npm i https://pkg.pr.new/@vitest/pretty-format@9026

@vitest/runner

npm i https://pkg.pr.new/@vitest/runner@9026

@vitest/snapshot

npm i https://pkg.pr.new/@vitest/snapshot@9026

@vitest/spy

npm i https://pkg.pr.new/@vitest/spy@9026

@vitest/ui

npm i https://pkg.pr.new/@vitest/ui@9026

@vitest/utils

npm i https://pkg.pr.new/@vitest/utils@9026

vitest

npm i https://pkg.pr.new/vitest@9026

@vitest/web-worker

npm i https://pkg.pr.new/@vitest/web-worker@9026

@vitest/ws-client

npm i https://pkg.pr.new/@vitest/ws-client@9026

commit: 0bba4cf

[netlify]

✅ Deploy Preview for vitest-dev ready!

Name	Link
🔨 Latest commit	0bba4cf
🔍 Latest deploy log	https://app.netlify.com/projects/vitest-dev/deploys/691ee8e4210b04000808743a
😎 Deploy Preview	https://deploy-preview-9026--vitest-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[sheremet-va]

Not sure how we can get rid of the stale cache without reducing the performance 🤔

[hi-ogawa]

Forgot to mention that I have a concern about transform cache when plugin collects module information through transform and feeds it other step (e.g. virtual module, or later output stage such as renderChunk) etc, but at the moment, I cannot think of concrete plugins breaking, especially because Vitest is Vite dev only and there's no common renderChunk replacement trick is needed.

One example which I thought might hit is tailwind, but now looking at it, it might have switched to its own fs crawling entirely.

[hi-ogawa]

Have you considered nuking cache based on lockfile like Vite's deps optimizer? That can at least cover packaged plugin change.

[sheremet-va]

Have you considered nuking cache based on lockfile like Vite's deps optimizer? That can at least cover packaged plugin change.

That could work, yeah.

[hi-ogawa]

The update looks good.

I quickly reviewed through Vite's builtin plugins and one feature which can get broken by the cache is import.meta.glob like transform (e.g. import.meta.glob("./*"), import(`./{var}`) (dynamic import var), new URL(`./{var}`, import.meta.url) (asset/worker import url)).

Another type of breakage is, user's tsconfig can affecting builtin esbuild/oxc transform and also 3rd party tsconfig plugin with paths alias. I think this is "less surprising" breakage since it's an obvious config change. Similar can happen when simply tweaking option for any plugin until defineCacheKeyGenerator is implemented.

I don't think this is blocking the experimental feature though. The question is, should we handle known patterns (at least for Vite builtin plugin) to bail out caching or do we add defineCacheKeyGenerator to upstream?

---

One more thing I just remembered is Rollup has shouldTransformCachedModule hook to let plugin decide cache https://rollupjs.org/plugin-development/#shouldtransformcachedmodule. I don't think Vite supports this and I don't think it's straight forward to actually reuse the same hook signature, but just sharing as a reference. For example, searching this hook https://github.com/search?q=shouldTransformCachedModule&type=code might show plugins which can break with fs cache.

[sheremet-va]

I quickly reviewed through Vite's builtin plugins and one feature which can get broken by the cache is import.meta.glob like transform (e.g. import.meta.glob("./*"), import(./{var}) (dynamic import var), new URL(./{var}, import.meta.url) (asset/worker import url)).

This is now addressed in the latest commit (only import.meta.glob). I don't have a solution for dynamic imports or assets for now, let's return to it after the release. For now there is a custom workaround with defineCacheKeyGenerator:

defineCacheKeyGenerator(({ sourceCode }) => {
  // assuming every new URL is dynamic
  if (sourceCode.includes('new URL')) {
    return false // false means don't cache this
  }
})

Dynamic imports and assets are also only affected in the client environment (jsdom/happy-dom).

Similar can happen when simply tweaking option for any plugin until defineCacheKeyGenerator is implemented.

This should not be a problem because we include the content of the config file and its dependencies inside the hash.

Adding a few more tests and it should be good to go.