VItest 4.1.6 is slow when running many projects

[n0th1ng-else]

Describe the bug

Hello, dear team. I am curious to clarify one thing. First, the intro:

I am in the process of migrating our main application from Jest to Vitest. The stats to think of: ~7000 test files in ~830 yarn workspaces.
While I was doing my pre-migration research, I took the biggest workspace and tried to migrate it, then compared the numbers.

Vitest performed slightly better compared to our current Jest + swc parser setup.

Now we are doing the actual migration. So far, we have migrated ~2400 test files in ~400 workspaces.
At this moment, I realized that Vitest is so slow that I need to stop now and investigate it.

These are the stats I see on CI (we run 3 shards with tests now):

1. 7714 tests, duration  943.50s (transform 9483.82s, setup 1395.21s, import 11947.48s, tests 216.35s, environment 318.46s)
2. 7678 tests, duration  941.40s (transform 9406.38s, setup 1369.58s, import 11797.43s, tests 187.65s, environment 310.80s)
3. 7856 tests, duration  1032.34s (transform 10515.15s, setup 1263.49s, import 13200.26s, tests 213.12s, environment 311.74s)

In total, it gives ~8 tests per second

Now this is the problem. I think I tried almost everything configuration-wide (appreciate your input if I missed something).

What is showing the actual difference now is merging the projects.

in our setup, we create a single vitest config file, and we define every workspace as a separate project entity. So we have the config with 400 projects right now. Most of the packages have the same local config, so I can just create an aggregated project in the config and include like 90% of the packages into a single aggregated project (ie instead of 400 projects, I ran 41 projects).

I just done an experiment with this and these are the numbers:

1. 8027  tests, duration  549.61s (transform 4353.24s, setup 1120.30s, import 6445.03s, tests 200.65s, environment 268.11s)
2. 8014  tests, duration  514.05s (transform 4151.33s, setup 1025.60s, import 6019.75s, tests 161.77s, environment 236.51s)
3. 8271  tests, duration  510.41s (transform 3943.84s, setup 974.85s, import 5938.06s, tests 178.16s, environment 236.56s)

In total, it gives ~15,4 tsts per second

So the difference in almost 2x

I am curious to hear from you - if it is an intended behavior? Anything I could do better in our situation?

Thank you!

Reproduction

n/a for now, private repository

System Info

System:
    OS: macOS 26.4.1
    CPU: (12) arm64 Apple M2 Pro
    Memory: 185.94 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 24.12.0 - /Users/sen/.nvm/versions/node/v24.12.0/bin/node
    Yarn: 4.10.1 - /opt/homebrew/bin/yarn
    npm: 11.6.2 - /Users/sen/.nvm/versions/node/v24.12.0/bin/npm
    pnpm: 10.33.0 - /Users/sen/Library/pnpm/pnpm
    bun: 1.3.5 - /Users/sen/.bun/bin/bun
    Deno: 2.5.6 - /Users/sen/.deno/bin/deno
  Browsers:
    Chrome: 149.0.7827.103
    Firefox: 151.0.4
    Safari: 26.4

Used Package Manager

yarn

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[hi-ogawa]

It's natural expectation that there's some overhead for splitting tests into multiple projects. For example, projects allow isolating vite's transform pipeline and thus there might be less benefit for transform cache.

To diagnose better, we would need concrete context on workspace setup and test configuration.

[n0th1ng-else]

hi @hi-ogawa thank you for the reply. Yes feels logical now as I look at it from this angle. was not obvious to debug at all.

we would need concrete context on workspace setup and test configuration.

not sure if I can share much, but let me know if you need something specific.

this is the base config which all packages and global unified config for CI inherits:

export default defineConfig({
	plugins: [
		getDefineGlobalsPlugin(),
		getCerebralPlugin(),
		getSvgrMockPlugin(),
		getStyleIdentityPlugin(),
		getTranslationMockPlugin(),
		getJSAsFileImportPlugin(),
		getStripFileQueryPlugin(),
		getBinaryFileMockPlugin(),
		getInlineLoaderMockPlugin(),
		getJSAsFileMockPlugin(),
		getCatchAllMockMockPlugin(),
	],
	test: {
		pool: 'threads',
		reporters: isCI ? ['default', 'github-actions', new MemoryReporter()] : ['default'],
		clearMocks: true,
		css: false,
		globals: true,
		include: ['**/*.{test,spec}.?(c|m)[jt]s?(x)'],
		exclude: ['/node_modules/'],
		setupFiles: ['vitest-canvas-mock', getFileFromSharedFolder('vitest.polyfills.ts')],
		silent: 'passed-only',
		environment: 'jsdom',
		environmentOptions: {
			jsdom: {
				url: 'http://localhost',
			},
		},
})

[n0th1ng-else]

now the global CI config is

export default mergeConfig(
	baseConfig,
	defineProject({
		test: {
			projects: getProjects(),
		},
	})
)

getProjects() is walking over the ./packages and looks up the custom vitest config.

• if the custom config exist, we load the custom one
• if not, we load the default one (base config I sent above)

custom vitest config are mostly add extra setup step setupFiles: ['./vitest.setup.ts'], and that's all

[n0th1ng-else]

projects allow isolating vite's transform pipeline

this also affects the transform cache size, right?